Providing Virtualized Private Network tunnels

ABSTRACT

Various aspects of the disclosure relate to providing a per-application policy-controlled virtual private network (VPN) tunnel. In some embodiments, tickets may be used to provide access to an enterprise resource without separate authentication of the application and, in some instances, can be used in such a manner as to provide a seamless experience to the user when reestablishing a per-application policy controlled VPN tunnel during the lifetime of the ticket. Additional aspects relate to an access gateway providing updated policy information and tickets to a mobile device. Other aspects relate to selectively wiping the tickets from a secure container of the mobile device. Yet further aspects relate to operating applications in multiple modes, such as a managed mode and an unmanaged mode, and providing authentication-related services based on one or more of the above aspects.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to: U.S. Provisional Patent ApplicationSer. No. 61/861,909, filed Aug. 2, 2013, and entitled “PROVIDINGVIRTUALIZED PRIVATE NETWORK TUNNELS;” U.S. Provisional PatentApplication Ser. No. 61/713,763, filed Oct. 15, 2012, and entitled“PER-APPLICATION POLICY-CONTROLLED ACCESS TO COMPUTERIZED RESOURCES;”and U.S. Provisional Patent Application Ser. No. 61/806,557, filed Mar.29, 2013, and entitled “SYSTEMS AND METHODS FOR ENTERPRISE MOBILITYMANAGEMENT.”

Each of the above-mentioned patent applications is incorporated byreference herein in its entirety.

BACKGROUND

Aspects of the disclosure relate to computer hardware and software. Inparticular, one or more aspects of the disclosure generally relate tocomputer hardware and software for providing an enterprise applicationstore.

Increasingly, corporations and other organizations are providing and/orotherwise enabling their employees and other associates with mobiledevices, such as smart phones, tablet computers, and other mobilecomputing devices. As these devices continue to grow in popularity andprovide an increasing number of functions, many organizations may wishto place certain controls on how these devices can be used, whatresources these devices can access, and how the applications running onthese devices can interact with other resources.

SUMMARY

Aspects of the disclosure provide more efficient, effective, functional,and convenient ways of controlling how mobile devices can be used, whatresources mobile devices can access, and how the applications running onthese devices can interact with other resources. In particular, in oneor more embodiments discussed in greater detail below, an enterpriseapplication store may be implemented that can provide these andfeatures.

Various aspects of the disclosure relate to providing a per-applicationpolicy-controlled VPN tunnel. In some embodiments, tickets may be usedto provide access to an enterprise resource without separateauthentication of the application. For example, some aspects may relateto a mobile device receiving policy information that describes one ormore policies for providing an application of the mobile device withaccess to at least one resource accessible through an access gateway;determining that the mobile device has a ticket that is valid, saidticket being configured to provide authentication in connection withcreating a virtual private network (VPN) tunnel for the application tosaid at least one resource; analyzing policy information to determinethat network access to the at least one resource is permitted;transmitting the ticket to the access gateway; and creating the VPNtunnel for the application to access said at least one resource.

Additional aspects may relate to updating policy information andtransmitting a ticket for a managed application to a mobile device. Forexample, some aspects may relate to one or more computing devices, suchas an access gateway, performing an update to policy information storedat an access gateway, wherein the policy information describes one ormore policies for providing an application of a mobile device withaccess to at least one enterprise resource accessible through the accessgateway, said update resulting in updated policy information;determining to transmit updated policy information to the mobile device;transmitting the updated policy information to the mobile device;transmitting a ticket to the mobile device, said ticket being configuredto provide authentication in connection with creating a virtual privatenetwork (VPN) tunnel for the application to said at least one resource;and opening the VPN tunnel to provide the application with access to theat least one resource.

Further aspects may relate to performing a deletion of tickets or otherdata associated with the mobile device, such as by performing aselective wipe. For example, some aspects may relate to a mobile devicestoring a ticket in a secure container usable to store data related to amanaged application being provided by the mobile device, wherein theticket is configured to provide authentication in connection withcreating a virtual private network (VPN) tunnel for the managedapplication to at least one resource accessible through an accessgateway; providing the managed application with access to the at leastone resource based on the ticket, the VPN tunnel, and policy informationthat describes one or more policies for providing the managedapplication of the apparatus with access to the at least one resource;determining to perform a selective wipe; determining that the ticket isstored by the mobile device; and deleting the ticket from the securecontainer.

Yet further aspects may relate to operating a managed application in atleast two modes of operation and providing access to resources via aper-application policy controlled virtual private network tunnel in atleast one of the modes of operation. For example, some aspects mayrelate to a mobile device determining a context for a managedapplication; based on at least two different operating modes,determining an operation mode for the managed application based on thecontext; executing the managed application in the operation mode; andproviding the managed application with access to at least one resourceaccessible through an access gateway based at least on a virtual privatenetwork (VPN) tunnel for the managed application to the at least oneresource, a ticket configured to provide authentication in connectionwith creating the VPN tunnel, and policy information that describes oneor more policies for providing the managed application of the apparatuswith access to the at least one resource.

Further aspects may relate to responding to authentication challengesautomatically or instead of the user or managed application. Forexample, some aspects may relate to a mobile device receiving anauthentication challenge in connection with an authentication processfor a managed application; analyzing policy information to determinethat the policy information allows the mobile device to respond to theauthentication challenge instead of a user or the managed application,wherein the policy information describes one or more policies forproviding the managed application with access to at least one resourceaccessible through an access gateway; responding, by the mobile device,to the authentication challenge instead of the user or the managedapplication; and providing the managed application with access to the atleast one resource based at least on a virtual private network (VPN)tunnel for the managed application to the at least one resource, aticket configured to provide authentication in connection with creatingthe VPN tunnel, and the policy information.

These features, along with many others, are discussed in greater detailbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 depicts an illustrative computer system architecture that may beused in accordance with one or more aspects of the disclosure.

FIG. 2 depicts an illustrative remote-access system architecture thatmay be used in accordance with various aspects of the disclosure.

FIG. 3 depicts an illustrative virtualized (hypervisor) systemarchitecture that may be used in accordance one or more aspects of thedisclosure.

FIG. 4 depicts an illustrative cloud-based system architecture that maybe used in accordance various aspects of the disclosure.

FIG. 5 depicts an illustrative enterprise mobility management systemthat may be used in accordance with one or more aspects of thedisclosure.

FIG. 6 depicts another illustrative enterprise mobility managementsystem that may be used in accordance with various aspects of thedisclosure.

FIG. 7 shows an electronic environment which enables an electronicmobile device to securely access a computerized resource via per-apppolicy-controlled VPN tunneling according to one or more aspects of thedisclosure.

FIG. 8 shows particular details of one embodiment of a suitable mobileelectronic device on which aspects related to securely accessing acomputerized resource may be practiced in accordance with variousaspects of the disclosure.

FIG. 9 illustrates a method that enables a mobile electronic device toaccess a computerized resource via an application specific tunnelaccording to one or more aspects described herein.

FIG. 10 illustrates a method of providing managed applications withper-application policies for accessing enterprise resources inaccordance with one or more illustrative aspects discussed herein.

FIG. 11 illustrates a method of providing a selective wipe of datarelated to providing per-application policy-controlled VPN tunnelsaccording to various aspects described herein.

FIGS. 12A-12F illustrate example methods of determining a context andoperation mode for an application according to one or more aspectsdescribed herein.

FIG. 12G illustrates an example method of switching an operation modefor an application.

FIGS. 13A-13C illustrate example methods for providingauthentication-related functionality in accordance with various aspectsdescribed herein.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings identified above and which form a parthereof, and in which is shown by way of illustration various embodimentsin which aspects described herein may be practiced. It is to beunderstood that other embodiments may be utilized and structural andfunctional modifications may be made without departing from the scopedescribed herein. Various aspects are capable of other embodiments andof being practiced or being carried out in various different ways.

As a general introduction to the subject matter described in more detailbelow, various aspects of the disclosure relate to providing aper-application policy-controlled VPN tunnel. In some embodiments,tickets may be used to provide access to an enterprise resource withoutseparate authentication of the application and, in some instances, canbe used in such a manner as to provide a seamless experience to the userwhen reestablishing a per-application policy controlled VPN tunnelduring the lifetime of the ticket. Additional aspects relate to anaccess gateway providing updated policy information and tickets to amobile device. Other aspects relate to selectively wiping the ticketsfrom a secure container of the mobile device. Yet further aspects relateto operating applications in multiple modes, such as a managed mode andan unmanaged mode, and providing authentication-related services basedon one or more of the above aspects.

It is to be understood that the phraseology and terminology used hereinare for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof. The use of the terms “mounted,” “connected,”“coupled,” “positioned,” “engaged” and similar terms, is meant toinclude both direct and indirect mounting, connecting, coupling,positioning and engaging.

Computing Architecture

Computer software, hardware, and networks may be utilized in a varietyof different system environments, including standalone, networked,remote-access (aka, remote desktop), virtualized, and/or cloud-basedenvironments, among others. FIG. 1 illustrates one example of a systemarchitecture and data processing device that may be used to implementone or more illustrative aspects described herein in a standalone and/ornetworked environment. Various network nodes 103, 105, 107, and 109 maybe interconnected via a wide area network (WAN) 101, such as theInternet. Other networks may also or alternatively be used, includingprivate intranets, corporate networks, LANs, metropolitan area networks(MAN) wireless networks, personal networks (PAN), and the like. Network101 is for illustration purposes and may be replaced with fewer oradditional computer networks. A local area network (LAN) may have one ormore of any known LAN topology and may use one or more of a variety ofdifferent protocols, such as Ethernet. Devices 103, 105, 107, 109 andother devices (not shown) may be connected to one or more of thenetworks via twisted pair wires, coaxial cable, fiber optics, radiowaves or other communication media.

The term “network” as used herein and depicted in the drawings refersnot only to systems in which remote storage devices are coupled togethervia one or more communication paths, but also to stand-alone devicesthat may be coupled, from time to time, to such systems that havestorage capability. Consequently, the term “network” includes not only a“physical network” but also a “content network,” which is comprised ofthe data—attributable to a single entity—which resides across allphysical networks.

The components may include data server 103, web server 105, and clientcomputers 107, 109. Data server 103 provides overall access, control andadministration of databases and control software for performing one ormore illustrative aspects describe herein. Data server 103 may beconnected to web server 105 through which users interact with and obtaindata as requested. Alternatively, data server 103 may act as a webserver itself and be directly connected to the Internet. Data server 103may be connected to web server 105 through the network 101 (e.g., theInternet), via direct or indirect connection, or via some other network.Users may interact with the data server 103 using remote computers 107,109, e.g., using a web browser to connect to the data server 103 via oneor more externally exposed web sites hosted by web server 105. Clientcomputers 107, 109 may be used in concert with data server 103 to accessdata stored therein, or may be used for other purposes. For example,from client device 107 a user may access web server 105 using anInternet browser, as is known in the art, or by executing a softwareapplication that communicates with web server 105 and/or data server 103over a computer network (such as the Internet).

Servers and applications may be combined on the same physical machines,and retain separate virtual or logical addresses, or may reside onseparate physical machines. FIG. 1 illustrates just one example of anetwork architecture that may be used, and those of skill in the artwill appreciate that the specific network architecture and dataprocessing devices used may vary, and are secondary to the functionalitythat they provide, as further described herein. For example, servicesprovided by web server 105 and data server 103 may be combined on asingle server.

Each component 103, 105, 107, 109 may be any type of known computer,server, or data processing device. Data server 103, e.g., may include aprocessor 111 controlling overall operation of the rate server 103. Dataserver 103 may further include RAM 113, ROM 115, network interface 117,input/output interfaces 119 (e.g., keyboard, mouse, display, printer,etc.), and memory 121. I/O 119 may include a variety of interface unitsand drives for reading, writing, displaying, and/or printing data orfiles. Memory 121 may further store operating system software 123 forcontrolling overall operation of the data processing device 103, controllogic 125 for instructing data server 103 to perform aspects describedherein, and other application software 127 providing secondary, support,and/or other functionality which may or might not be used in conjunctionwith aspects described herein. The control logic may also be referred toherein as the data server software 125. Functionality of the data serversoftware may refer to operations or decisions made automatically basedon rules coded into the control logic, made manually by a user providinginput into the system, and/or a combination of automatic processingbased on user input (e.g., queries, data updates, etc.).

Memory 121 may also store data used in performance of one or moreaspects described herein, including a first database 129 and a seconddatabase 131. In some embodiments, the first database may include thesecond database (e.g., as a separate table, report, etc.). That is, theinformation can be stored in a single database, or separated intodifferent logical, virtual, or physical databases, depending on systemdesign. Devices 105, 107, 109 may have similar or different architectureas described with respect to device 103. Those of skill in the art willappreciate that the functionality of data processing device 103 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc.

One or more aspects may be embodied in computer-usable or readable dataand/or computer-executable instructions, such as in one or more programmodules, executed by one or more computers or other devices as describedherein. Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types when executed by a processor ina computer or other device. The modules may be written in a source codeprogramming language that is subsequently compiled for execution, or maybe written in a scripting language such as (but not limited to) HTML orXML. The computer executable instructions may be stored on a computerreadable medium such as a nonvolatile storage device. Any suitablecomputer readable storage media may be utilized, including hard disks,CD-ROMs, optical storage devices, magnetic storage devices, and/or anycombination thereof. In addition, various transmission (non-storage)media representing data or events as described herein may be transferredbetween a source and a destination in the form of electromagnetic wavestraveling through signal-conducting media such as metal wires, opticalfibers, and/or wireless transmission media (e.g., air and/or space).Various aspects described herein may be embodied as a method, a dataprocessing system, or a computer program product. Therefore, variousfunctionalities may be embodied in whole or in part in software,firmware and/or hardware or hardware equivalents such as integratedcircuits, field programmable gate arrays (FPGA), and the like.Particular data structures may be used to more effectively implement oneor more aspects described herein, and such data structures arecontemplated within the scope of computer executable instructions andcomputer-usable data described herein.

With further reference to FIG. 2, one or more aspects described hereinmay be implemented in a remote-access environment. FIG. 2 depicts anexample system architecture including a generic computing device 201 inan illustrative computing environment 200 that may be used according toone or more illustrative aspects described herein. Generic computingdevice 201 may be used as a server 206 a in a single-server ormulti-server desktop virtualization system (e.g., a remote access orcloud system) configured to provide virtual machines for client accessdevices. The generic computing device 201 may have a processor 203 forcontrolling overall operation of the server and its associatedcomponents, including random access memory (RAM) 205, read-only memory(ROM) 207, input/output (I/O) module 209, and memory 215.

I/O module 209 may include a mouse, keypad, touch screen, scanner,optical reader, and/or stylus (or other input device(s)) through which auser of generic computing device 201 may provide input, and may alsoinclude one or more of a speaker for providing audio output and a videodisplay device for providing textual, audiovisual, and/or graphicaloutput. Software may be stored within memory 215 and/or other storage toprovide instructions to processor 203 for configuring generic computingdevice 201 into a special purpose computing device in order to performvarious functions as described herein. For example, memory 215 may storesoftware used by the computing device 201, such as an operating system217, application programs 219, and an associated database 221.

Computing device 201 may operate in a networked environment supportingconnections to one or more remote computers, such as terminals 240 (alsoreferred to as client devices). The terminals 240 may be personalcomputers, mobile devices, laptop computers, tablets, or servers thatinclude many or all of the elements described above with respect to thegeneric computing device 103 or 201. The network connections depicted inFIG. 2 include a local area network (LAN) 225 and a wide area network(WAN) 229, but may also include other networks. When used in a LANnetworking environment, computing device 201 may be connected to the LAN225 through a network interface or adapter 223. When used in a WANnetworking environment, computing device 201 may include a modem 227 orother wide area network interface for establishing communications overthe WAN 229, such as computer network 230 (e.g., the Internet). It willbe appreciated that the network connections shown are illustrative andother means of establishing a communications link between the computersmay be used. Computing device 201 and/or terminals 240 may also bemobile terminals (e.g., mobile phones, smartphones, PDAs, notebooks,etc.) including various other components, such as a battery, speaker,and antennas (not shown).

Aspects described herein may also be operational with numerous othergeneral purpose or special purpose computing system environments orconfigurations. Examples of other computing systems, environments,and/or configurations that may be suitable for use with aspectsdescribed herein include, but are not limited to, personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

As shown in FIG. 2, one or more client devices 240 may be incommunication with one or more servers 206 a-206 n (generally referredto herein as “server(s) 206”). In one embodiment, the computingenvironment 200 may include a network appliance installed between theserver(s) 206 and client machine(s) 240. The network appliance maymanage client/server connections, and in some cases can load balanceclient connections amongst a plurality of backend servers 206.

The client machine(s) 240 may in some embodiments be referred to as asingle client machine 240 or a single group of client machines 240,while server(s) 206 may be referred to as a single server 206 or asingle group of servers 206. In one embodiment a single client machine240 communicates with more than one server 206, while in anotherembodiment a single server 206 communicates with more than one clientmachine 240. In yet another embodiment, a single client machine 240communicates with a single server 206.

A client machine 240 can, in some embodiments, be referenced by any oneof the following non-exhaustive terms: client machine(s); client(s);client computer(s); client device(s); client computing device(s); localmachine; remote machine; client node(s); endpoint(s); or endpointnode(s). The server 206, in some embodiments, may be referenced by anyone of the following non-exhaustive terms: server(s), local machine;remote machine; server farm(s), or host computing device(s).

In one embodiment, the client machine 240 may be a virtual machine. Thevirtual machine may be any virtual machine, while in some embodimentsthe virtual machine may be any virtual machine managed by a Type 1 orType 2 hypervisor, for example, a hypervisor developed by CitrixSystems, IBM, VMware, or any other hypervisor. In some aspects, thevirtual machine may be managed by a hypervisor, while in aspects thevirtual machine may be managed by a hypervisor executing on a server 206or a hypervisor executing on a client 240.

Some embodiments include a client device 240 that displays applicationoutput generated by an application remotely executing on a server 206 orother remotely located machine. In these embodiments, the client device240 may execute a virtual machine receiver program or application todisplay the output in an application window, a browser, or other outputwindow. In one example, the application is a desktop, while in otherexamples the application is an application that generates or presents adesktop. A desktop may include a graphical shell providing a userinterface for an instance of an operating system in which local and/orremote applications can be integrated. Applications, as used herein, areprograms that execute after an instance of an operating system (and,optionally, also the desktop) has been loaded.

The server 206, in some embodiments, uses a remote presentation protocolor other program to send data to a thin-client or remote-displayapplication executing on the client to present display output generatedby an application executing on the server 206. The thin-client orremote-display protocol can be any one of the following non-exhaustivelist of protocols: the Independent Computing Architecture (ICA) protocoldeveloped by Citrix Systems, Inc. of Ft. Lauderdale, Fla.; or the RemoteDesktop Protocol (RDP) manufactured by the Microsoft Corporation ofRedmond, Wash.

A remote computing environment may include more than one server 206a-206 n such that the servers 206 a-206 n are logically grouped togetherinto a server farm 206, for example, in a cloud computing environment.The server farm 206 may include servers 206 that are geographicallydispersed while and logically grouped together, or servers 206 that arelocated proximate to each other while logically grouped together.Geographically dispersed servers 206 a-206 n within a server farm 206can, in some embodiments, communicate using a WAN (wide), MAN(metropolitan), or LAN (local), where different geographic regions canbe characterized as: different continents; different regions of acontinent; different countries; different states; different cities;different campuses; different rooms; or any combination of the precedinggeographical locations. In some embodiments the server farm 206 may beadministered as a single entity, while in other embodiments the serverfarm 206 can include multiple server farms.

In some embodiments, a server farm may include servers 206 that executea substantially similar type of operating system platform (e.g.,WINDOWS, UNIX, LINUX, iOS, ANDROID, SYMBIAN, etc.) In other embodiments,server farm 206 may include a first group of one or more servers thatexecute a first type of operating system platform, and a second group ofone or more servers that execute a second type of operating systemplatform.

Server 206 may be configured as any type of server, as needed, e.g., afile server, an application server, a web server, a proxy server, anappliance, a network appliance, a gateway, an application gateway, agateway server, a virtualization server, a deployment server, a SSL VPNserver, a firewall, a web server, an application server or as a masterapplication server, a server executing an active directory, or a serverexecuting an application acceleration program that provides firewallfunctionality, application functionality, or load balancingfunctionality. Other server types may also be used.

Some embodiments include a first server 106 a that receives requestsfrom a client machine 240, forwards the request to a second server 106b, and responds to the request generated by the client machine 240 witha response from the second server 106 b. First server 106 a may acquirean enumeration of applications available to the client machine 240 andwell as address information associated with an application server 206hosting an application identified within the enumeration ofapplications. First server 106 a can then present a response to theclient's request using a web interface, and communicate directly withthe client 240 to provide the client 240 with access to an identifiedapplication. One or more clients 240 and/or one or more servers 206 maytransmit data over network 230, e.g., network 101.

FIG. 2 shows a high-level architecture of an illustrative desktopvirtualization system. As shown, the desktop virtualization system maybe single-server or multi-server system, or cloud system, including atleast one virtualization server 206 configured to provide virtualdesktops and/or virtual applications to one or more client accessdevices 240. As used herein, a desktop refers to a graphical environmentor space in which one or more applications may be hosted and/orexecuted. A desktop may include a graphical shell providing a userinterface for an instance of an operating system in which local and/orremote applications can be integrated. Applications may include programsthat execute after an instance of an operating system (and, optionally,also the desktop) has been loaded. Each instance of the operating systemmay be physical (e.g., one operating system per device) or virtual(e.g., many instances of an OS running on a single device). Eachapplication may be executed on a local device, or executed on a remotelylocated device (e.g., remoted).

With further reference to FIG. 3, a computer device 301 may beconfigured as a virtualization server in a virtualization environment,for example, a single-server, multi-server, or cloud computingenvironment. Virtualization server 301 illustrated in FIG. 3 can bedeployed as and/or implemented by one or more embodiments of the server206 illustrated in FIG. 2 or by other known computing devices. Includedin virtualization server 301 is a hardware layer that can include one ormore physical disks 304, one or more physical devices 306, one or morephysical processors 308 and one or more physical memories 316. In someembodiments, firmware 312 can be stored within a memory element in thephysical memory 316 and can be executed by one or more of the physicalprocessors 308. Virtualization server 301 may further include anoperating system 314 that may be stored in a memory element in thephysical memory 316 and executed by one or more of the physicalprocessors 308. Still further, a hypervisor 302 may be stored in amemory element in the physical memory 316 and can be executed by one ormore of the physical processors 308.

Executing on one or more of the physical processors 308 may be one ormore virtual machines 332A-C (generally 332). Each virtual machine 332may have a virtual disk 326A-C and a virtual processor 328A-C. In someembodiments, a first virtual machine 332A may execute, using a virtualprocessor 328A, a control program 320 that includes a tools stack 324.Control program 320 may be referred to as a control virtual machine,Dom0, Domain 0, or other virtual machine used for system administrationand/or control. In some embodiments, one or more virtual machines 332B-Ccan execute, using a virtual processor 328B-C, a guest operating system330A-B.

Virtualization server 301 may include a hardware layer 310 with one ormore pieces of hardware that communicate with the virtualization server301. In some embodiments, the hardware layer 310 can include one or morephysical disks 304, one or more physical devices 306, one or morephysical processors 308, and one or more memory 216. Physical components304, 306, 308, and 316 may include, for example, any of the componentsdescribed above. Physical devices 306 may include, for example, anetwork interface card, a video card, a keyboard, a mouse, an inputdevice, a monitor, a display device, speakers, an optical drive, astorage device, a universal serial bus connection, a printer, a scanner,a network element (e.g., router, firewall, network address translator,load balancer, virtual private network (VPN) gateway, Dynamic HostConfiguration Protocol (DHCP) router, etc.), or any device connected toor communicating with virtualization server 301. Physical memory 316 inthe hardware layer 310 may include any type of memory. Physical memory316 may store data, and in some embodiments may store one or moreprograms, or set of executable instructions. FIG. 3 illustrates anembodiment where firmware 312 is stored within the physical memory 316of virtualization server 301. Programs or executable instructions storedin the physical memory 316 can be executed by the one or more processors308 of virtualization server 301.

Virtualization server 301 may also include a hypervisor 302. In someembodiments, hypervisor 302 may be a program executed by processors 308on virtualization server 301 to create and manage any number of virtualmachines 332. Hypervisor 302 may be referred to as a virtual machinemonitor, or platform virtualization software. In some embodiments,hypervisor 302 can be any combination of executable instructions andhardware that monitors virtual machines executing on a computingmachine. Hypervisor 302 may be Type 2 hypervisor, where the hypervisorthat executes within an operating system 314 executing on thevirtualization server 301. Virtual machines then execute at a levelabove the hypervisor. In some embodiments, the Type 2 hypervisorexecutes within the context of a user's operating system such that theType 2 hypervisor interacts with the user's operating system. In otherembodiments, one or more virtualization servers 201 in a virtualizationenvironment may instead include a Type 1 hypervisor (not shown). A Type1 hypervisor may execute on the virtualization server 301 by directlyaccessing the hardware and resources within the hardware layer 310. Thatis, while a Type 2 hypervisor 302 accesses system resources through ahost operating system 314, as shown, a Type 1 hypervisor may directlyaccess all system resources without the host operating system 314. AType 1 hypervisor may execute directly on one or more physicalprocessors 308 of virtualization server 301, and may include programdata stored in the physical memory 316.

Hypervisor 302, in some embodiments, can provide virtual resources tooperating systems 330 or control programs 320 executing on virtualmachines 332 in any manner that simulates the operating systems 330 orcontrol programs 320 having direct access to system resources. Systemresources can include, but are not limited to, physical devices 306,physical disks 304, physical processors 308, physical memory 316 and anyother component included in virtualization server 301 hardware layer310. Hypervisor 302 may be used to emulate virtual hardware, partitionphysical hardware, virtualize physical hardware, and/or execute virtualmachines that provide access to computing environments. In still otherembodiments, hypervisor 302 controls processor scheduling and memorypartitioning for a virtual machine 332 executing on virtualizationserver 301. Hypervisor 302 may include those manufactured by VMWare,Inc., of Palo Alto, Calif.; the XEN hypervisor, an open source productwhose development is overseen by the open source Xen.org community;HyperV, VirtualServer or virtual PC hypervisors provided by Microsoft,or others. In some embodiments, virtualization server 301 executes ahypervisor 302 that creates a virtual machine platform on which guestoperating systems may execute. In these embodiments, the virtualizationserver 301 may be referred to as a host server. An example of such avirtualization server is the XEN SERVER provided by Citrix Systems,Inc., of Fort Lauderdale, Fla.

Hypervisor 302 may create one or more virtual machines 332B-C (generally332) in which guest operating systems 330 execute. In some embodiments,hypervisor 302 may load a virtual machine image to create a virtualmachine 332. In other embodiments, the hypervisor 302 may executes aguest operating system 330 within virtual machine 332. In still otherembodiments, virtual machine 332 may execute guest operating system 330.

In addition to creating virtual machines 332, hypervisor 302 may controlthe execution of at least one virtual machine 332. In other embodiments,hypervisor 302 may presents at least one virtual machine 332 with anabstraction of at least one hardware resource provided by thevirtualization server 301 (e.g., any hardware resource available withinthe hardware layer 310). In other embodiments, hypervisor 302 maycontrol the manner in which virtual machines 332 access physicalprocessors 308 available in virtualization server 301. Controllingaccess to physical processors 308 may include determining whether avirtual machine 332 should have access to a processor 308, and howphysical processor capabilities are presented to the virtual machine332.

As shown in FIG. 3, virtualization server 301 may host or execute one ormore virtual machines 332. A virtual machine 332 is a set of executableinstructions that, when executed by a processor 308, imitate theoperation of a physical computer such that the virtual machine 332 canexecute programs and processes much like a physical computing device.While FIG. 3 illustrates an embodiment where a virtualization server 301hosts three virtual machines 332, in other embodiments virtualizationserver 301 can host any number of virtual machines 332. Hypervisor 302,in some embodiments, provides each virtual machine 332 with a uniquevirtual view of the physical hardware, memory, processor and othersystem resources available to that virtual machine 332. In someembodiments, the unique virtual view can be based on one or more ofvirtual machine permissions, application of a policy engine to one ormore virtual machine identifiers, a user accessing a virtual machine,the applications executing on a virtual machine, networks accessed by avirtual machine, or any other desired criteria. For instance, hypervisor302 may create one or more unsecure virtual machines 332 and one or moresecure virtual machines 332. Unsecure virtual machines 332 may beprevented from accessing resources, hardware, memory locations, andprograms that secure virtual machines 332 may be permitted to access. Inother embodiments, hypervisor 302 may provide each virtual machine 332with a substantially similar virtual view of the physical hardware,memory, processor and other system resources available to the virtualmachines 332.

Each virtual machine 332 may include a virtual disk 326A-C (generally326) and a virtual processor 328A-C (generally 328.) The virtual disk326, in some embodiments, is a virtualized view of one or more physicaldisks 304 of the virtualization server 301, or a portion of one or morephysical disks 304 of the virtualization server 301. The virtualizedview of the physical disks 304 can be generated, provided and managed bythe hypervisor 302. In some embodiments, hypervisor 302 provides eachvirtual machine 332 with a unique view of the physical disks 304. Thus,in these embodiments, the particular virtual disk 326 included in eachvirtual machine 332 can be unique when compared with the other virtualdisks 326.

A virtual processor 328 can be a virtualized view of one or morephysical processors 308 of the virtualization server 301. In someembodiments, the virtualized view of the physical processors 308 can begenerated, provided and managed by hypervisor 302. In some embodiments,virtual processor 328 has substantially all of the same characteristicsof at least one physical processor 308. In other embodiments, virtualprocessor 308 provides a modified view of physical processors 308 suchthat at least some of the characteristics of the virtual processor 328are different than the characteristics of the corresponding physicalprocessor 308.

With further reference to FIG. 4, some aspects described herein may beimplemented in a cloud-based environment. FIG. 4 illustrates an exampleof a cloud computing environment (or cloud system) 400. As seen in FIG.4, client computers 411-414 may communicate with a cloud managementserver 410 to access the computing resources (e.g., host servers 403,storage resources 404, and network resources 405) of the cloud system.

Management server 410 may be implemented on one or more physicalservers. The management server 410 may run, for example, CLOUDSTACK byCitrix Systems, Inc. of Ft. Lauderdale, Fla., or OPENSTACK, amongothers. Management server 410 may manage various computing resources,including cloud hardware and software resources, for example, hostcomputers 403, data storage devices 404, and networking devices 405. Thecloud hardware and software resources may include private and/or publiccomponents. For example, a cloud may be configured as a private cloud tobe used by one or more particular customers or client computers 411-414and/or over a private network. In other embodiments, public clouds orhybrid public-private clouds may be used by other customers over an openor hybrid networks.

Management server 410 may be configured to provide user interfacesthrough which cloud operators and cloud customers may interact with thecloud system. For example, the management server 410 may provide a setof APIs and/or one or more cloud operator console applications (e.g.,web-based on standalone applications) with user interfaces to allowcloud operators to manage the cloud resources, configure thevirtualization layer, manage customer accounts, and perform other cloudadministration tasks. The management server 410 also may include a setof APIs and/or one or more customer console applications with userinterfaces configured to receive cloud computing requests from end usersvia client computers 411-414, for example, requests to create, modify,or destroy virtual machines within the cloud. Client computers 411-414may connect to management server 410 via the Internet or othercommunication network, and may request access to one or more of thecomputing resources managed by management server 410. In response toclient requests, the management server 410 may include a resourcemanager configured to select and provision physical resources in thehardware layer of the cloud system based on the client requests. Forexample, the management server 410 and additional components of thecloud system may be configured to provision, create, and manage virtualmachines and their operating environments (e.g., hypervisors, storageresources, services offered by the network elements, etc.) for customersat client computers 411-414, over a network (e.g., the Internet),providing customers with computational resources, data storage services,networking capabilities, and computer platform and application support.Cloud systems also may be configured to provide various specificservices, including security systems, development environments, userinterfaces, and the like.

Certain clients 411-414 may be related, for example, different clientcomputers creating virtual machines on behalf of the same end user, ordifferent users affiliated with the same company or organization. Inother examples, certain clients 411-414 may be unrelated, such as usersaffiliated with different companies or organizations. For unrelatedclients, information on the virtual machines or storage of any one usermay be hidden from other users.

Referring now to the physical hardware layer of a cloud computingenvironment, availability zones 401-402 (or zones) may refer to acollocated set of physical computing resources. Zones may begeographically separated from other zones in the overall cloud ofcomputing resources. For example, zone 401 may be a first clouddatacenter located in California, and zone 402 may be a second clouddatacenter located in Florida. Management sever 410 may be located atone of the availability zones, or at a separate location. Each zone mayinclude an internal network that interfaces with devices that areoutside of the zone, such as the management server 410, through agateway. End users of the cloud (e.g., clients 411-414) might or mightnot be aware of the distinctions between zones. For example, an end usermay request the creation of a virtual machine having a specified amountof memory, processing power, and network capabilities. The managementserver 410 may respond to the user's request and may allocate theresources to create the virtual machine without the user knowing whetherthe virtual machine was created using resources from zone 401 or zone402. In other examples, the cloud system may allow end users to requestthat virtual machines (or other cloud resources) are allocated in aspecific zone or on specific resources 403-405 within a zone.

In this example, each zone 401-402 may include an arrangement of variousphysical hardware components (or computing resources) 403-405, forexample, physical hosting resources (or processing resources), physicalnetwork resources, physical storage resources, switches, and additionalhardware resources that may be used to provide cloud computing servicesto customers. The physical hosting resources in a cloud zone 401-402 mayinclude one or more computer servers 403, such as the virtualizationservers 301 described above, which may be configured to create and hostvirtual machine instances. The physical network resources in a cloudzone 401 or 402 may include one or more network elements 405 (e.g.,network service providers) comprising hardware and/or softwareconfigured to provide a network service to cloud customers, such asfirewalls, network address translators, load balancers, virtual privatenetwork (VPN) gateways, Dynamic Host Configuration Protocol (DHCP)routers, and the like. The storage resources in the cloud zone 401-402may include storage disks (e.g., solid state drives (SSDs), magnetichard disks, etc.) and other storage devices.

The example cloud computing environment shown in FIG. 4 also may includea virtualization layer (e.g., as shown in FIGS. 1-3) with additionalhardware and/or software resources configured to create and managevirtual machines and provide other services to customers using thephysical resources in the cloud. The virtualization layer may includehypervisors, as described above in FIG. 3, along with other componentsto provide network virtualizations, storage virtualizations, etc. Thevirtualization layer may be as a separate layer from the physicalresource layer, or may share some or all of the same hardware and/orsoftware resources with the physical resource layer. For example, thevirtualization layer may include a hypervisor installed in each of thevirtualization servers 403 with the physical computing resources. Knowncloud systems may alternatively be used, e.g., WINDOWS AZURE (MicrosoftCorporation of Redmond Wash.), AMAZON EC2 (Amazon.com Inc. of Seattle,Wash.), IBM BLUE CLOUD (IBM Corporation of Armonk, N.Y.), or others.

Enterprise Mobility Management Architecture

FIG. 5 represents an enterprise mobility technical architecture 500 foruse in a BYOD environment. The architecture enables a user of a mobiledevice 502 to both access enterprise or personal resources from a mobiledevice 502 and use the mobile device 502 for personal use. The user mayaccess such enterprise resources 504 or enterprise services 508 using amobile device 502 that is purchased by the user or a mobile device 502that is provided by the enterprise to user. The user may utilize themobile device 502 for business use only or for business and personaluse. The mobile device may run an iOS operating system, and Androidoperating system, or the like. The enterprise may choose to implementpolicies to manage the mobile device 504. The policies may be implantedthrough a firewall or gateway in such a way that the mobile device maybe identified, secured or security verified, and provided selective orfull access to the enterprise resources. The policies may be mobiledevice management policies, mobile application management policies,mobile data management policies, or some combination of mobile device,application, and data management policies. A mobile device 504 that ismanaged through the application of mobile device management policies maybe referred to as a managed device or an enrolled device.

The operating system of the mobile device may be separated into amanaged partition 510 and an unmanaged partition 512. The managedpartition 510 may have policies applied to it to secure the applicationsrunning on and data stored in the managed partition. The applicationsrunning on the managed partition may be secure applications. In otherembodiments, all applications may execute in accordance with a set ofone or more policy files received separate from the application, andwhich define one or more security parameters, features, resourcerestrictions, and/or other access controls that are enforced by themobile device management system when that application is executing onthe device. By operating in accordance with their respective policyfile(s), each application may be allowed or restricted fromcommunications with one or more other applications and/or resources,thereby creating a virtual partition. Thus, as used herein, a partitionmay refer to a physically partitioned portion of memory (physicalpartition), a logically partitioned portion of memory (logicalpartition), and/or a virtual partition created as a result ofenforcement of one or more policies and/or policy files across multipleapps as described herein (virtual partition). Stated differently, byenforcing policies on managed apps, those apps may be restricted to onlybe able to communicate with other managed apps and trusted enterpriseresources, thereby creating a virtual partition that is impenetrable byunmanaged apps and devices.

The secure applications may be email applications, web browsingapplications, software-as-a-service (SaaS) access applications, WindowsApplication access applications, and the like. The secure applicationsmay be secure native applications 514, secure remote applications 522executed by a secure application launcher 518, virtualizationapplications 526 executed by a secure application launcher 518, and thelike. The secure native applications 514 may be wrapped by a secureapplication wrapper 520. The secure application wrapper 520 may includeintegrated policies that are executed on the mobile device 502 when thesecure native application is executed on the device. The secureapplication wrapper 520 may include meta-data that points the securenative application 514 running on the mobile device 502 to the resourceshosted at the enterprise that the secure native application 514 mayrequire to complete the task requested upon execution of the securenative application 514. The secure remote applications 522 executed by asecure application launcher 518 may be executed within the secureapplication launcher application 518. The virtualization applications526 executed by a secure application launcher 518 may utilize resourceson the mobile device 502, at the enterprise resources 504, and the like.The resources used on the mobile device 502 by the virtualizationapplications 526 executed by a secure application launcher 518 mayinclude user interaction resources, processing resources, and the like.The user interaction resources may be used to collect and transmitkeyboard input, mouse input, camera input, tactile input, audio input,visual input, gesture input, and the like. The processing resources maybe used to present a user interface, process data received from theenterprise resources 504, and the like. The resources used at theenterprise resources 504 by the virtualization applications 526 executedby a secure application launcher 518 may include user interfacegeneration resources, processing resources, and the like. The userinterface generation resources may be used to assemble a user interface,modify a user interface, refresh a user interface, and the like. Theprocessing resources may be used to create information, readinformation, update information, delete information, and the like. Forexample, the virtualization application may record user interactionsassociated with a GUI and communicate them to a server application wherethe server application will use the user interaction data as an input tothe application operating on the server. In this arrangement, anenterprise may elect to maintain the application on the server side aswell as data, files, etc. associated with the application. While anenterprise may elect to “mobilize” some applications in accordance withthe principles herein by securing them for deployment on the mobiledevice, this arrangement may also be elected for certain applications.For example, while some applications may be secured for use on themobile device, others might not be prepared or appropriate fordeployment on the mobile device so the enterprise may elect to providethe mobile user access to the unprepared applications throughvirtualization techniques. As another example, the enterprise may havelarge complex applications with large and complex data sets (e.g.,material resource planning applications) where it would be verydifficult, or otherwise undesirable, to customize the application forthe mobile device so the enterprise may elect to provide access to theapplication through virtualization techniques. As yet another example,the enterprise may have an application that maintains highly secureddata (e.g. human resources data, customer data, engineering data) thatmay be deemed by the enterprise as too sensitive for even the securedmobile environment so the enterprise may elect to use virtualizationtechniques to permit mobile access to such applications and data. Anenterprise may elect to provide both fully secured and fully functionalapplications on the mobile device as well as a virtualizationapplication to allow access to applications that are deemed moreproperly operated on the server side. In an embodiment, thevirtualization application may store some data, files, etc. on themobile phone in one of the secure storage locations. An enterprise, forexample, may elect to allow certain information to be stored on thephone while not permitting other information.

In connection with the virtualization application, as described herein,the mobile device may have a virtualization application that is designedto present GUI's and then record user interactions with the GUI. Theapplication may communicate the user interactions to the server side tobe used by the server side application as user interactions with theapplication. In response, the application on the server side maytransmit back to the mobile device a new GUI. For example, the new GUImay be a static page, a dynamic page, an animation, or the like, therebyproviding access to remotely located resources.

The applications running on the managed partition may be stabilizedapplications. The stabilized applications may be managed by a devicemanager 524. The device manager 524 may monitor the stabilizedapplications and utilize techniques for detecting and remedying problemsthat would result in a destabilized application if such techniques werenot utilized to detect and remedy the problems.

The secure applications may access data stored in a secure datacontainer 528 in the managed partition 510 of the mobile device. Thedata secured in the secure data container may be accessed by the securewrapped applications 514, applications executed by a secure applicationlauncher 522, virtualization applications 526 executed by a secureapplication launcher 522, and the like. The data stored in the securedata container 528 may include files, databases, and the like. The datastored in the secure data container 528 may include data restricted to aspecific secure application 530, shared among secure applications 532,and the like. Data restricted to a secure application may include securegeneral data 534 and highly secure data 538. Secure general data may usea strong form of encryption such as AES 128-bit encryption or the like,while highly secure data 538 may use a very strong form of encryptionsuch as AES 254-bit encryption. Data stored in the secure data container528 may be deleted from the device upon receipt of a command from thedevice manager 524. The secure applications may have a dual-mode option540. The dual mode option 540 may present the user with an option tooperate the secured application in an unsecured or unmanaged mode. In anunsecured or unmanaged mode, the secure applications may access datastored in an unsecured data container 542 on the unmanaged partition 512of the mobile device 502. The data stored in an unsecured data containermay be personal data 544. The data stored in an unsecured data container542 may also be accessed by unsecured applications 548 that are runningon the unmanaged partition 512 of the mobile device 502. The data storedin an unsecured data container 542 may remain on the mobile device 502when the data stored in the secure data container 528 is deleted fromthe mobile device 502. An enterprise may want to delete from the mobiledevice selected or all data, files, and/or applications owned, licensedor controlled by the enterprise (enterprise data) while leaving orotherwise preserving personal data, files, and/or applications owned,licensed or controlled by the user (personal data). This operation maybe referred to as a selective wipe. With the enterprise and personaldata arranged in accordance to the aspects described herein, anenterprise may perform a selective wipe.

The mobile device may connect to enterprise resources 504 and enterpriseservices 508 at an enterprise, to the public Internet 548, and the like.The mobile device may connect to enterprise resources 504 and enterpriseservices 508 through virtual private network connections such as, forexample, a microVPN or application-specifc VPN. The virtual privatenetwork connections may be specific to particular applications 550,particular devices, particular secured areas on the mobile device, andthe like 552. For example, each of the wrapped applications in thesecured area of the phone may access enterprise resources through anapplication specific VPN such that access to the VPN would be grantedbased on attributes associated with the application, possibly inconjunction with user or device attribute information. The virtualprivate network connections may carry Microsoft Exchange traffic,Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic,application management traffic, and the like. The virtual privatenetwork connections may support and enable single-sign-on authenticationprocesses 554. The single-sign-on processes may allow a user to providea single set of authentication credentials, which are then verified byan authentication service 558. The authentication service 558 may thengrant to the user access to multiple enterprise resources 504, withoutrequiring the user to provide authentication credentials to eachindividual enterprise resource 504.

The virtual private network connections may be established and managedby an access gateway 560. The access gateway 560 may include performanceenhancement features that manage, accelerate, and improve the deliveryof enterprise resources 504 to the mobile device 502. The access gatewaymay also re-route traffic from the mobile device 502 to the publicInternet 548, enabling the mobile device 502 to access publiclyavailable and unsecured applications that run on the public Internet548. The mobile device may connect to the access gateway via a transportnetwork 562. The transport network 562 may be a wired network, wirelessnetwork, cloud network, local area network, metropolitan area network,wide area network, public network, private network, and the like.

The enterprise resources 504 may include email servers, file sharingservers, SaaS applications, Web application servers, Windows applicationservers, and the like. Email servers may include Exchange servers, LotusNotes servers, and the like. File sharing servers may include ShareFileservers, and the like. SaaS applications may include Salesforce, and thelike. Windows application servers may include any application serverthat is built to provide applications that are intended to run on alocal Windows operating system, and the like. The enterprise resources504 may be premise-based resources, cloud based resources, and the like.The enterprise resources 504 may be accessed by the mobile device 502directly or through the access gateway 560. The enterprise resources 504may be accessed by the mobile device 502 via a transport network 562.The transport network 562 may be a wired network, wireless network,cloud network, local area network, metropolitan area network, wide areanetwork, public network, private network, and the like.

The enterprise services 508 may include authentication services 558,threat detection services 564, device manager services 524, file sharingservices 568, policy manager services 570, social integration services572, application controller services 574, and the like. Authenticationservices 558 may include user authentication services, deviceauthentication services, application authentication services, dataauthentication services and the like. Authentication services 558 mayuse certificates. The certificates may be stored on the mobile device502, by the enterprise resources 504, and the like. The certificatesstored on the mobile device 502 may be stored in an encrypted locationon the mobile device, the certificate may be temporarily stored on themobile device 502 for use at the time of authentication, and the like.Threat detection services 564 may include intrusion detection services,unauthorized access attempt detection services, and the like.Unauthorized access attempt detection services may include unauthorizedattempts to access devices, applications, data, and the like. Devicemanagement services 524 may include configuration, provisioning,security, support, monitoring, reporting, and decommissioning services.File sharing services 568 may include file management services, filestorage services, file collaboration services, and the like. Policymanager services 570 may include device policy manager services,application policy manager services, data policy manager services, andthe like. Social integration services 572 may include contactintegration services, collaboration services, integration with socialnetworks such as Facebook, Twitter, and LinkedIn, and the like.Application controller services 574 may include management services,provisioning services, deployment services, assignment services,revocation services, wrapping services, and the like.

The enterprise mobility technical architecture 500 may include anapplication store 578. The application store 578 may include unwrappedapplications 580, pre-wrapped applications 582, and the like.Applications may be populated in the application store 578 from theapplication controller 574. The application store 578 may be accessed bythe mobile device 502 through the access gateway 560, through the publicInternet 548, or the like. The application store may be provided with anintuitive and easy to use User Interface. The application store 578 mayprovide access to a software development kit 584. The softwaredevelopment kit 584 may provide a user the capability to secureapplications selected by the user by wrapping the application asdescribed previously in this description. An application that has beenwrapped using the software development kit 584 may then be madeavailable to the mobile device 502 by populating it in the applicationstore 578 using the application controller 574.

The enterprise mobility technical architecture 500 may include amanagement and analytics capability 588. The management and analyticscapability 588 may provide information related to how resources areused, how often resources are used, and the like. Resources may includedevices, applications, data, and the like. How resources are used mayinclude which devices download which applications, which applicationsaccess which data, and the like. How often resources are used mayinclude how often an application has been downloaded, how many times aspecific set of data has been accessed by an application, and the like.

FIG. 6 is another illustrative enterprise mobility management system600. Some of the components of the mobility management system 500described above with reference to FIG. 5 have been omitted for the sakeof simplicity. The architecture of the system 600 depicted in FIG. 6 issimilar in many respects to the architecture of the system 500 describedabove with reference to FIG. 5 and may include additional features notmentioned above.

In this case, the left hand side represents an enrolled mobile device602 with a client agent 604, which interacts with gateway server 606(which includes access gateway and application controller functionality)to access various enterprise resources 608 and services 609 such asExchange, Sharepoint, PKI Resources, Kerberos Resources, CertificateIssuance service, as shown on the right hand side above. Although notspecifically shown, the mobile device 602 may also interact with anenterprise application store for the selection and downloading ofapplications.

The client agent 604 acts as the UI (user interface) intermediary forWindows apps/desktops hosted in an Enterprise data center, which areaccessed using the HDX/ICA display remoting protocol. The client agent604 also supports the installation and management of native applicationson the mobile device 602, such as native iOS or Android applications.For example, the managed applications 610 (mail, browser, wrappedapplication, secure container to which a VPN, such as anapplication-specific policy-controlled VPN can connect to) shown in thefigure above are all native applications that execute locally on thedevice. Client agent 604 and application management framework of thisarchitecture act to provide policy driven management capabilities andfeatures such as connectivity and SSO (single sign on) to enterpriseresources/services 608. The client agent 604 handles primary userauthentication to the enterprise, normally to Access Gateway (AG) withSSO to other gateway server components. The client agent 604 obtainspolicies from gateway server 606 to control the behavior of the managedapplications 610 on the mobile device 602.

The Secure IPC links 612 between the native applications 610 and clientagent 604 represent a management channel, which allows client agent tosupply policies to be enforced by the application management framework614 “wrapping” each application. The IPC channel 612 also allows clientagent 604 to supply credential and authentication information thatenables connectivity and SSO to enterprise resources 608. Finally theIPC channel 612 allows the application management framework 614 toinvoke user interface functions implemented by client agent 604, such asonline and offline authentication.

Communications between the client agent 604 and gateway server 606 areessentially an extension of the management channel from the applicationmanagement framework 614 wrapping each native managed application 610.The application management framework 614 requests policy informationfrom client agent 604, which in turn requests it from gateway server606. The application management framework 614 requests authentication,and client agent 604 logs into the gateway services part of gatewayserver 606 (also known as NetScaler Access Gateway). Client agent 604may also call supporting services on gateway server 606, which mayproduce input material to derive encryption keys for the local datavaults 616, or provide client certificates which may enable directauthentication to PKI protected resources, as more fully explainedbelow.

In more detail, the application management framework 614 “wraps” eachmanaged application 610. This may be incorporated via an explicit buildstep, or via a post-build processing step. The application managementframework 614 may “pair” with client agent 604 on first launch of anapplication 610 to initialize the Secure IPC channel and obtain thepolicy for that application. The application management framework 614may enforce relevant portions of the policy that apply locally, such asthe client agent login dependencies and some of the containment policiesthat restrict how local OS services may be used, or how they mayinteract with the application 610.

The application management framework 614 may use services provided byclient agent 604 over the Secure IPC channel 612 to facilitateauthentication and internal network access. Key management for theprivate and shared data vaults 616 (containers) may be also managed byappropriate interactions between the managed applications 610 and clientagent 604. Vaults 616 may be available only after online authentication,or may be made available after offline authentication if allowed bypolicy. First use of vaults 616 may require online authentication, andoffline access may be limited to at most the policy refresh periodbefore online authentication is again required.

Network access to internal resources may occur directly from individualmanaged applications 610 through Access Gateway 606. The applicationmanagement framework 614 is responsible for orchestrating the networkaccess on behalf of each application 610. Client agent 604 mayfacilitate these network connections by providing suitable time limitedsecondary credentials obtained following online authentication. Multiplemodes of network connection may be used, such as reverse web proxyconnections and end-to-end VPN-style tunnels 618.

The Mail and Browser managed applications 610 have special status andmay make use of facilities that might not be generally available toarbitrary wrapped applications. For example, the Mail application mayuse a special background network access mechanism that allows it toaccess Exchange over an extended period of time without requiring a fullAG logon. The Browser application may use multiple private data vaultsto segregate different kinds of data.

This architecture supports the incorporation of various other securityfeatures. For example, gateway server 606 (including its gatewayservices) in some cases will not need to validate AD passwords. It canbe left to the discretion of an enterprise whether an AD password isused as an authentication factor for some users in some situations.Different authentication methods may be used if a user is online oroffline (i.e., connected or not connected to a network).

Step up authentication is a feature wherein gateway server 606 mayidentify managed native applications 610 that are allowed to have accessto highly classified data requiring strong authentication, and ensurethat access to these applications is only permitted after performingappropriate authentication, even if this means a re-authentication isrequired by the user after a prior weaker level of login.

Another security feature of this solution is the encryption of the datavaults 616 (containers) on the mobile device 602. The vaults 616 may beencrypted so that all on-device data including files, databases, andconfigurations are protected. For on-line vaults, the keys may be storedon the server (gateway server 606), and for off-line vaults, a localcopy of the keys may be protected by a user password. When data isstored locally on the device 602 in the secure container 616, it ispreferred that a minimum of AES 256 encryption algorithm be utilized.

Other secure container features may also be implemented. For example, alogging feature may be included, wherein all security events happeninginside an application 610 are logged and reported to the backend. Datawiping may be supported, such as if the application 610 detectstampering, associated encryption keys may be written over with randomdata, leaving no hint on the file system that user data was destroyed.Screenshot protection is another feature, where an application mayprevent any data from being stored in screenshots. For example, the keywindow's hidden property may be set to YES. This may cause whatevercontent is currently displayed on the screen to be hidden, resulting ina blank screenshot where any content would normally reside.

Local data transfer may be prevented, such as by preventing any datafrom being locally transferred outside the application container, e.g.,by copying it or sending it to an external application. A keyboard cachefeature may operate to disable the autocorrect functionality forsensitive text fields. SSL certificate validation may be operable so theapplication specifically validates the server SSL certificate instead ofit being stored in the keychain. An encryption key generation featuremay be used such that the key used to encrypt data on the device isgenerated using a passphrase supplied by the user (if offline access isrequired). It may be XORed with another key randomly generated andstored on the server side if offline access is not required. KeyDerivation functions may operate such that keys generated from the userpassword use KDFs (key derivation functions, notably PBKDF2) rather thancreating a cryptographic hash of it. The latter makes a key susceptibleto brute force or dictionary attacks.

Further, one or more initialization vectors may be used in encryptionmethods. An initialization vector will cause multiple copies of the sameencrypted data to yield different cipher text output, preventing bothreplay and cryptanalytic attacks. This will also prevent an attackerfrom decrypting any data even with a stolen encryption key if thespecific initialization vector used to encrypt the data is not known.Further, authentication then decryption may be used, wherein applicationdata is decrypted only after the user has authenticated within theapplication. Another feature may relate to sensitive data in memory,which may be kept in memory (and not in disk) only when it's needed. Forexample, login credentials may be wiped from memory after login, andencryption keys and other data inside objective-C instance variables arenot stored, as they may be easily referenced. Instead, memory may bemanually allocated for these.

An inactivity timeout may be implemented, wherein after a policy-definedperiod of inactivity, a user session is terminated.

Data leakage from the application management framework 614 may beprevented in other ways. For example, when an application 610 is put inthe background, the memory may be cleared after a predetermined(configurable) time period. When backgrounded, a snapshot may be takenof the last displayed screen of the application to fasten theforegrounding process. The screenshot may contain confidential data andhence should be cleared.

Another security feature relates to the use of an OTP (one timepassword) 620 without the use of an AD (active directory) 622 passwordfor access to one or more applications. In some cases, some users do notknow (or are not permitted to know) their AD password, so these usersmay authenticate using an OTP 620 such as by using a hardware OTP systemlike SecurID (OTPs may be provided by different vendors also, such asEntrust or Gemalto). In some cases, after a user authenticates with auser ID, a text is sent to the user with an OTP 620. In some cases, thismay be implemented only for online use, with a prompt being a singlefield.

An offline password may be implemented for offline authentication forthose applications 610 for which offline use is permitted via enterprisepolicy. For example, an enterprise may want an enterprise application tobe accessed in this manner. In this case, the client agent 604 mayrequire the user to set a custom offline password and the AD password isnot used. Gateway server 606 may provide policies to control and enforcepassword standards with respect to the minimum length, character classcomposition, and age of passwords, such as described by the standardWindows Server password complexity requirements, although theserequirements may be modified.

Another feature relates to the enablement of a client side certificatefor certain applications 610 as secondary credentials (for the purposeof accessing PKI protected web resources via the application managementframework micro VPN feature). For example, an application may utilizesuch a certificate. In this case, certificate-based authentication usingActiveSync protocol may be supported, wherein a certificate from theclient agent 604 may be retrieved by gateway server 606 and used in akeychain. Each managed application may have one associated clientcertificate, identified by a label that is defined in gateway server606.

Gateway server 606 may interact with an Enterprise special purpose webservice to support the issuance of client certificates to allow relevantmanaged applications to authenticate to internal PKI protectedresources.

The client agent 604 and the application management framework 614 may beenhanced to support obtaining and using client certificates forauthentication to internal PKI protected network resources. More thanone certificate may be supported, such as to match various levels ofsecurity and/or separation requirements. The certificates may be used bythe Mail and Browser managed applications, and ultimately by arbitrarywrapped applications (provided those applications use web service stylecommunication patterns where it is reasonable for the applicationmanagement framework to mediate https requests).

Application management client certificate support on iOS may rely onimporting a PKCS 12 BLOB (Binary Large Object) into the iOS keychain ineach managed application for each period of use. Application managementframework client certificate support may use a HTTPS implementation withprivate in-memory key storage. The client certificate will never bepresent in the iOS keychain and will not be persisted except potentiallyin “online-only” data value that is strongly protected.

Mutual SSL may also be implemented to provide additional security byrequiring that a mobile device 602 is authenticated to the enterprise,and vice versa. Virtual smart cards for authentication to gateway server606 may also be implemented.

Both limited and full Kerberos support may be additional features. Thefull support feature relates to an ability to do full Kerberos login toActive Directory (AD) 622, using an AD password or trusted clientcertificate, and obtain Kerberos service tickets to respond to HTTPNegotiate authentication challenges. The limited support feature relatesto constrained delegation in AFEE, where AFEE supports invoking Kerberosprotocol transition so it can obtain and use Kerberos service tickets(subject to constrained delegation) in response to HTTP Negotiateauthentication challenges. This mechanism works in reverse web proxy(aka CVPN) mode, and when http (but not https) connections are proxiedin VPN and MicroVPN mode.

Another feature relates to application container locking and wiping,which may automatically occur upon jail-break or rooting detections, andoccur as a pushed command from administration console, and may include aremote wipe functionality even when an application 610 is not running.

A multi-site architecture or configuration of an enterprise applicationand application controller may be supported that allows users to beservice from one of several different locations in case of failure.

In some cases, managed applications 610 may be allowed to access acertificate and private key via an API (example OpenSSL). Trustedmanaged applications 610 of an enterprise may be allowed to performspecific Public Key operations with an application's client certificateand private key. Various use cases may be identified and treatedaccordingly, such as when an application behaves like a browser and nocertificate access is required, when an application reads a certificatefor “who am I,” when an application uses the certificate to build asecure session token, and when an application uses private keys fordigital signing of important data (e.g. transaction log) or fortemporary data encryption.

ILLUSTRATIVE EMBODIMENT(S)

FIG. 7 shows an electronic environment which enables an electronicmobile device to securely access a computerized resource viaper-application policy-controlled VPN tunneling. The cloud represents acommunications medium (e.g., a wireless computer network, the Internet,a cellular network, combinations thereof, and so on) which enables theelectronic mobile device to communicate with the remote access point.

FIG. 8 shows particular details of one embodiment of a suitable mobileelectronic device on which aspects related to securely accessing acomputerized resource, such as those shown in FIG. 7, may be practiced.As shown, the electronic mobile device includes, among other things, auser interface for user input/output, memory to store information, andprocessing circuitry. Examples of suitable mobile devices include smartphones, tablet devices, electronic notebooks, and so on. Furthermore,various specific platforms are suitable for use such as those runningiOS provided by Apple Computer, Android provided by Google, and Windowsprovided by Microsoft are suitable.

During operation, the mobile device builds per-applicationpolicy-controlled VPN-style connections between the specificapplications and a remote access point (e.g., a VPN server, a gateway,an individual computer, etc.).

FIG. 9 illustrates a method that is performed by the processingcircuitry of the mobile device when operating in accordance with varioussoftware constructs stored in the memory of the mobile device. Inparticular, the method enables the mobile device to access acomputerized resource via an application specific tunnel.

Access to enterprise servers is not a problem when the mobile device isconnected directly to a private wireless network or LAN. But when theuser's device is connected to a foreign network such as 3G/4G network,home-based WiFi, or other public access point, transparent networkaccess to corporate intranet is problematic without a VPN. However,because a system level VPN gives access to all the mobile deviceapplications uniformly, a better solution for managed enterpriseapplications is a per-application VPN technology that can be policycontrolled. In this case, VPN access is granted to specific users andapplications on the mobile electronic device only based on eachemployee's role within the organization. Non-enterprise applicationswould have no awareness of or access to resources inside of thecorporate intranet through this per-application VPN connection.

Many mobile resource management (MRM) solutions (also referred to hereinas EMM, MDM and MAM, each of which may include MRM) offer a virtualprivate network (VPN) solution as the mechanism for providing suchaccess. However, traditional VPNs have the downside that allapplications running on the mobile device are granted uniform access tothe corporate intranet. Increasingly, mobile devices used to accessenterprise resources are employee owned and not enrolled with an MDMserver, and therefore not tightly controlled or managed by a corporateIT department. As such, there is a real risk of malware and otherunauthorized software running on an employee's own mobile device to gainaccess to the corporate intranet when using traditional VPN software.Traditional system level VPN solutions do not discriminate betweentrusted and untrusted applications. By building in a per-applicationpolicy-controlled VPN solution, enterprises can ensure that onlyauthorized applications for authorized users in specifically configuredaccess scenarios are able to access corporate intranet resources from aforeign network.

In addition, by adjusting policy files, an enterprise can make policydecisions regarding whether to allow a MicroVPN, disallow a MicroVPN, ortunnel data from specific managed applications to and from theenterprise servers. Additionally, an enterprise can control networkaccess of a device at different levels of specificity. For example, onepolicy that can be used for an application is to let the applicationconnect to enterprise resources from any network, including foreignnetworks. Another policy could be used that specifies an application canonly access enterprise resources via a microVPN tunnel. A VPN tunnel mayalso be referred herein as a VPN connection.

At step 901, the mobile device may perform authentication with theenterprise and may include authenticating the user and/or the mobiledevice. A variety of authentication techniques may be employed, such assingle sign-on (SSO) credentials, and some techniques may require a userto supply usernames and/or passwords, or other form of credential. Inaddition, mobile device and/or access gateway may intercept networktraffic based on policy information and/or based on certificatesassociated with the user/device, and/or may respond to authenticationchallenges by virtue of seeing network level conversation. A mobiledevice, in some embodiments, is typically challenged to authenticate theuser's corporate identity along with passwords and other factors asdictated by corporate policy.

In some arrangements, the mobile device may receive policy informationfrom the enterprise, as illustrated at step 903 (e.g., the methodproceeds from step 901 to step 903). In some arrangements, the mobiledevice may request the policy information after successfullyauthenticating for the first time. In others, the mobile device mayrequest the policy information every time upon starting to manageexecution of the application. The access manager components of theenterprise may transmit the policy information (e.g., a policy that hasbeen established by the enterprise administrator for this user whenrequesting access to the enterprise resource) to the mobile device.

Additionally, the policy information may include one or more policiesspecific to the application (e.g., specifying network access for onlythe application). The application-specific policies may be cached (e.g.,in a secure container) and periodically refreshed to ensure compliancewith administrative settings. These application-specific policies mayfurther restrict access to the enterprise resource only during certaintimes, from certain networks, form certain geo-locations, and only fromdevices that are in compliance with all organizations security policies.

The policy information may also include one or more policies thatconstrain or provide privileges to the VPN tunnel. For example, thepolicy information may define the type or level of encryption that is tobe applied to data transmitted via the tunnel. The policy may specifythat an application may only access enterprise resources via a VPNtunnel, including a per-application policy-controlled VPN tunnel.

The policy information may include one or more policies that constrainwhat data traffic should use a VPN tunnel. For example, a policy mayinclude a tunnel setting that can be defined as on or off. When thesplit tunnel setting is set to on, the access gateway may control whatdata must be transmitted via an application specific VPN tunnel and whatdata can be transmitted in other ways (e.g., normal VPN connection orusing an unsecured connection). The access gateway, in some embodiments,may make the determination based on the destination of the data (e.g.,the uniform resource locator (URL) of the destination that the data isbeing transmitted to) or the resource that is being accessed. The accessgateway may communicate its determination to the mobile device eitherwhen transmitting the policy information or when the mobile deviceattempts to send the data or access the resource.

The policy information may include one or more policies that constrainwhat authentication information is required to access a resource orcreate an application specific VPN tunnel. Different policies mayrequire different levels of authentication, such as requiring a highersecurity authentication process when attempting to access highlysensitive data/resources than the authentication process that isrequired for accessing other data/resources. For example, a policy mayspecify that a valid ticket must be received from the managed devicebefore the resource can be accessed or the application specific VPNtunnel can be created. Alternatively, the policy may also specify thatthe managed device is to proceed through an authentication process(e.g., repeat an initial authentication process) prior to creating anapplication-specific VPN tunnel. In addition to the specifiedauthentication process, the policy may also require the managed deviceto supply a valid username and password prior to accessing the resourceor creating the application-specific VPN tunnel. Other forms ofauthentication that can be specified by policy include multi-factorschemes, single factor schemes, biometric schemes, passcode schemes,risk-based authentication schemes, and the like. The policy may alsospecify optional authentication schemes that if completed allow themanaged device or managed application with additional privileges, suchas access to highly protected resources or access to tickets with alonger validity duration.

The previous steps may, in some variations, illustrate steps performedby the mobile device to setup, initialize or maintain the management ofan application. For example, the above steps may be performed when auser first tries to access the enterprise resource using the applicationor the first time the application executes on the mobile device. Theabove steps may be performed periodically or as-needed by the mobiledevice to maintain proper authentication and stay up to date on policyinformation. An enterprise, or enterprise operator (e.g., IT technician)may be able to signal a mobile device to re-authenticate or updatepolicy information.

At step 905, the mobile device may determine whether the mobile devicehas a token or ticket that is valid. Such tickets or tokens (these termswill be used interchangeably herein) are offered in order toauthenticate the user in a transparent manner. That is, one or moretickets are provided to the mobile device from the enterprise in aneffort to avoid burdening the user to re-authenticate. When attemptingto access an enterprise resource or initiating a secure connection tothe enterprise resource, the mobile device may provide the ticket to theremote access point instead of reauthenticating. Nevertheless, it shouldbe understood that over time, such tickets may expire. The expiration ofa ticket may be specified by including a validity duration (e.g., a timeperiod of validity for the ticket or a date/time when the ticketexpires, etc.) within the ticket. If such tickets expire prior to use,operations that required tickets instead now require that the userre-authenticate. Additionally, tickets can be offered based on theresources that are attempted to be accessed. For example a ticket with along validity duration could be issued when attempting to access ane-mail resource, such as an Exchange server, while a ticket with ashorter validity duration could be issued when attempting to accessother resources.

A ticket may be first loaded into the mobile device during initialauthentication (e.g., at step 901) or when the policy information isreceived (e.g., at step 903). The ticket may be linked to the samecredentials that were previously used to logon and confirm entitlement.If such token/ticket has expired, then the user may be asked to proceedthrough the authentication process again before allowing VPN access.After authenticating to the gateway, the specialized network softwareconstructs a VPN tunnel through the gateway device to the actualintranet resource. However unlike other system level VPN solutions, thisVPN tunnel is only available for this specific application on the user'sdevice to use.

A ticket may be usable to provide authentication in connection withcreating a VPN tunnel to enterprise resources. For example, a ticket mayinclude data or be otherwise configured to authenticate a user, mobiledevice or application that is attempting to create a VPN tunnel to anenterprise resource that is accessible through an access gateway. Aticket may be one-time use and/or time-based, and impose constraintsand/or privileges to the application or user when accessing anenterprise resource. For example, a ticket may be specified as valid fora two-week period, or some other shorter or longer time period as theenterprise operator wishes (e.g., provide short-lived or longer-livedaccess). In some arrangements, access control is structured so that thelevel of security diminishes over time. For instance, some applicationswhich should have high security may be provided tickets that expire morequickly (e.g., after a predefined amount of time such as an hour, 15minutes, etc.). Other tickets associated with applications of lowersecurity may expire at a later time (e.g., after a later predefinedamount of time such as a day, etc.). Other ticket-based techniques forimposing different levels of security based on time or other measure(e.g., number of logins) are suitable for use as well.

In some arrangements, the policy for the application may specify thatthe application can access the enterprise resource using a ticket.Additionally, in some arrangements, the policy or the ticket itself mayspecify the time period for which the token is valid. The ticket mayinclude a code or identifier that uniquely identifies the ticket, user,application or mobile device to the enterprise (or mobile device).

Referring again to step 905, determining whether the mobile device has avalid ticket can be performed in various ways. For example, the mobiledevice may first search for a ticket (e.g., determine whether the mobiledevice is storing a ticket for the application) and, if found, determineif the ticket is valid (e.g., determine whether the ticket has notexpired in accordance with the time-period associated with the ticket).In some arrangements, the mobile device may determine whether the policyincludes a ticket or otherwise indicates that the application's accessto the enterprise resource is based on a ticket. The mobile device maysearch a secure container for a ticket. Upon finding a ticket, theticket, and other information related to the ticket, may be analyzed todetermine whether the ticket is valid.

In some arrangements, the ticket may include a timestamp indicating astatus for the ticket (e.g., a timestamp of “12:00 on Jan. 1, 2012”indicating the initial time for the ticket; or a number of accessesindicating the number of times the enterprise resources has beenaccessed using the ticket). Additionally, the ticket or the policy forthe application may include an indication describing a condition as towhen the ticket expires (e.g., a time-period such as two-weeks, one day,forever, etc.; a number of accesses to the enterprise resource such asone access, ten accesses, infinite accesses, etc.). Based on the statusand the indication, the mobile device may determine whether the tickethas expired. If the ticket has expired, the mobile device has a ticketthat is not valid. Otherwise, the ticket has not expired and the mobiledevice has a ticket that is valid.

In some instances, the mobile device may not find a ticket stored at themobile device. In such instances, it may be determined that the mobiledevice does not have a ticket that is valid.

Upon determining that the mobile device has a ticket that is valid, themethod may proceed to step 909. Otherwise, the mobile device has aticket that is not valid and the method may proceed to step 907.

At step 907, the mobile device may re-authenticate (e.g., in a mannersimilar to step 901) and may obtain a new ticket. In some arrangements,the policy information may also be updated. Subsequently, the methodproceeds to step 905 to validate the new ticket.

At step 909, the mobile device may analyze the policy information forcompliance with any condition or rule related to the applicationaccessing the enterprise resource. For example, the current policyinformation may be checked to determine if network access should bepermitted. Assuming the mobile device is running on a foreign networkand the enterprise administrator has permitted VPN access for thisapplication for this user, then a secure connection may be initiated tothe enterprise gateway device.

If policy information dictates no network access, then the mobile devicemay fail to connect to the enterprise. If the network access policypermits network usage but does not permit VPN access, then networkservice calls are routed directly to the mobile device platform networkservices though the local network that the device is attached to ratherthan being tunneled back to the corporate intranet. Additional networkpolicies can further constrain the range of corporate intranet serversthat are accessible by IP address, domain or host names, port/protocol,TCP/UDP, etc.

At step 911, the mobile device may transmit the ticket to theenterprise. The enterprise may perform its own validation on the ticket.The enterprise may transmit an acknowledgement of receipt or result ofits validation to the mobile device and, in such arrangements, themobile device may proceed to step 913 upon receiving the communicationfrom the enterprise.

At step 913, the mobile device may create a per-applicationpolicy-controlled VPN tunnel to the enterprise resource, such as aMicroVPN tunnel similar to those illustrated in FIG. 5. This tunnel maybe created with the enterprise gateway device. Subsequently, the mobiledevice may proceed to access the enterprise resource via theper-application policy-controlled VPN tunnel. For example, the user may,if the application is a mail client, access e-mail related services andthe like. Upon successful creation of the tunnel, the mobile device may,in some arrangements, update the ticket (e.g., increment the number oflogins if the status describes a number of logins).

In view of steps 905-913, a mobile device may, based on the ticket,receive access to an enterprise resource without separateauthentication. For example, the ticket can be used to access theenterprise resource until it expires despite the VPN tunnel timing outor otherwise losing the VPN connection to the enterprise resource.Indeed, assuming the ticket stays valid, if the user closes the VPNtunnel and at a later time decides to access the enterprise resourceagain (e.g., see if any new e-mail has been received), steps 905, 909,911 and 913 may be repeated with the ticket to access the enterpriseresource without repeating step 901 or 909. In some arrangements, such aprocess of regaining access to the enterprise resource by reusing theticket may occur without knowledge of the user (e.g., performed in thebackground or without any indication being provided to the user as tothe process of recreating the VPN tunnel). Such a process can provide aseamless experience to the user.

In addition to being used to provide access to an enterprise resourcewithout separate authentication of the application, user or mobiledevice, a valid ticket may be used in other ways. For example, someapplications may provide presence-related functionality, such as anindication of whether a user is idle or online. The application may,based on the ticket, provide one or more servers of the enterprise withinformation required to enable the presence-related functionality.Indeed, the application may provide the ticket to a server (e.g., aserver accessible through the access gateway, or otherwise provided bythe enterprise). The server may be able to determine the user that theticket is related to and set the status of the user as online or notidle.

The above-provided description may discuss particular operations of theapplications figuratively (e.g., as the applications performing theoperations). However, it is actually the processing circuitry of themobile device that may perform operations while executing theapplications.

As described above, when a mobile computing device accesses anenterprise computer/IT system, sensitive information or data associatedwith the enterprise and/or enterprise-related software applications canbecome stored onto the mobile device. Enterprise-related data cancomprise any data associated with the enterprise, such as, withoutlimitation, product information, sales data, customer lists, businessperformance data, proprietary know-how, new innovation and research,trade secrets, and the like. Because this information can be verysensitive, an enterprise may wish to safeguard such information.

Further, enterprises may wish to regulate how users use their mobiledevices. For example, enterprises may want some control over where themobile devices are used, which mobile device features can be used, whichsoftware applications can be installed and/or run on the devices, andthe like. Enterprises also have a need to control and implement remedialactions for users that violate their mobile device usage policies.

When users in the field experience problems with their mobile devices orcould benefit from information, data, software, or coaching on how toperform certain operations using the devices, it can be difficult forthe enterprise's IT support to provide highly effective assistance.Accordingly, there is a need for improved secure management andtechnical support of mobile devices associated with an enterprise.Management of any device, application, or accessible tool is sometimesreferred to as MDM or MRM. Enterprises may manage devices, applications,software, settings, features, remote tools, virtualized apps, etc.

Embodiments described herein address these and other concerns. Thepresent application discloses computer systems and methods for automatedor semi-automated management of mobile computing devices that access anenterprise computer network, such as access to computer-implementedresources of the enterprise.

More particularly, as described above (e.g., in connection with FIG. 5and FIG. 9, etc.), a mobile device (e.g., mobile device 502) cancommunicate with enterprise resources (resources 504) via an accessgateway (access gateway 560) and, for example, a microVPN tunnel.Further, the enterprise can use the tunnel to send information back tothe mobile device, such as data responsive to an access request.

When a user executes a managed application on the mobile device, theuser is typically challenged to authenticate the user's identity alongwith passwords and other factors as dictated by corporate rules. Afterauthentication, the mobile device may be provided with a policy fordetermining how the managed application is to perform network accesses.By basing one or more policies on enrollment in MRM, a policy can bebased on information not otherwise known to the mobile device, but whichis known through the MRM service.

For example, when enrolled in MRM, the enterprise (e.g., access gatewayor a MRM server) may store information regarding whether or not a mobiledevice has a device level PIN enabled, device level encryption, securitycertificate information, and any other information that the enterprisehas access to through enterprise level management of the mobile device.Thus, a policy, in one embodiment, may specify a policy decision onwhether or not the mobile device has a device level PIN enabled. Inanother example, policy may set a policy decision based on whether ornot the mobile device has device level encryption enabled. In anotherexample, the policy may set a policy decision based on whether or notthe mobile device has been provisioned with a required certificate toaccess a particular enterprise resource. For example, an internalenterprise web site might require that the device be provisioned with acertificate from the enterprise. In addition, the converse may alsooccur. For example, the enterprise may grant a certificate to a mobiledevice when applicable policy information allows the device (orapplication) to access a particular resource that requires a certificateadministered by the enterprise.

FIG. 10 illustrates a method of providing managed applications withper-application policies for accessing enterprise resources. In one ormore embodiments, the example method of FIG. 10 may be performed by theprocessing circuitry of an access gateway when operating in accordancewith various software constructs stored in the memory of the accessgateway.

At step 1001, an access gateway (or MRM server) may update policyinformation. The policy information may be related to or be for aparticular application installed a particular user's mobile device. Inone or more arrangements, the access gateway may update policyinformation based on information that is stored by, maintained by,and/or accessible to the access gateway, such as a listing ofapplications that are installed on the mobile device and/or a listing oftickets that are issued and currently valid for the mobile device. Insome instances (and as more fully discussed below), such information maybe created, accessed, modified, and/or stored by the access gatewaybased on input and/or other information received from an administrativeuser of the enterprise network (e.g., an administrative user may input alisting of managed applications installed on the mobile device).

Additionally, such information may be created, accessed, modified,and/or stored by the access gateway based on network traffic to/from themobile device and the enterprise network (e.g., the access gateway mayupdate a list of tickets whenever a ticket is transmitted or issued tothe mobile device in connection with providing access to enterpriseresources on the basis of a per-application policy-controlled VPNtunnel, as described in connection with FIG. 9). The listing of ticketsor listing of applications may also be associated with informationidentifying the user of the mobile device and/or any credentials used toauthenticate the user.

Furthermore, such information may be created, accessed, modified and/orstored by the access gateway based on one or more risk determinations.For example, the access gateway may determine a risk score according toone or more risk-based authentication rules. If the risk score is aboveor below a particular threshold, the access gateway maycreate/access/modify/store policy information that requires a managedapplication or managed device to perform particular authenticationprocesses. In some arrangements, if the risk score is above thethreshold, the access gateway may require a more secure authenticationprocess before allowing access to a resource or allowing creation of anapplication-specific VPN tunnel. If the risk score is below thethreshold, the access gateway may require a less secure authenticationprocess before allowing access to a resource or allowing creation of anapplication-specific VPN tunnel. Among the many different types ofauthentication processes the access gateway may require based on therisk score are, for example, multi-factor schemes, single factorschemes, biometric schemes, passcode schemes, risk-based authenticationschemes, and the like.

At step 1003, an access gateway may determine to transmit an update tothe policy information. In some embodiments, the determination to updatepolicy information may be based on receiving a request for policyinformation from a mobile device or from a mobile device attempting tocreate a microVPN tunnel. In some embodiments, this determination toupdate policy information may be based on information received fromanother enterprise entity (e.g., an enterprise operator sends a signalto the access gateway to update policy information) or based on adetermination to update policy information performed by the accessgateway (e.g., if access gateway is configured to periodically updatepolicy information).

At step 1005, the access gateway may transmit the updated policyinformation to the mobile device. Upon receipt, the mobile device maystore the policy information in an appropriate location (e.g., a securecontainer) and may implement the policies specified in the information.

At step 1007, the access gateway may transmit a ticket to the mobiledevice. Based on transmitting the ticket, the access gateway may updatethe listing of applications or tickets. For example, the access gatewaymay update the listing of tickets to add the ticket and, in somearrangements, other information related to the ticket (e.g., anidentification of the application the ticket is issued to) to thelisting; or update the listing of tickets to update an entry alreadypresent on the listing. As another example, the access gateway mayupdate the listing of applications with an identification of theapplication that the ticket was issued to.

While steps 1005 and 1007 are illustrated as separate steps, they may becombined into a single step in some arrangements. For example, if theticket is included in the policy information, the ticket would betransmitted when transmitting the updated policy information.

At step 1009, the access gateway may open a per-applicationpolicy-controlled VPN tunnel for an application that is requestingaccess to an enterprise resource. Opening of the tunnel may be initiatedresponsive to one or more requests made by the mobile device. Inconnection with or when requesting a per-application policy-controlledVPN tunnel, a mobile device may transmit a copy of a ticket to theaccess gateway and/or an identification of the application that isrequesting the enterprise resource. The access gateway may compare thecopy of the ticket to the listing of tickets and, if the ticket ispresent on the listing, reply with an acknowledgement or an indicationthat the ticket has been validated by the access gateway.

In some embodiments, the steps of FIG. 10 may be performed based oninput received via a user interface that is accessible to an operator ofthe enterprise. For example, an information technology technicianemployed by the enterprise may view a user interface in order to create,access, modify and/or store policy information at the access gateway(e.g., step 1001 of FIG. 10), cause the access gateway to send an updateto the policy information (e.g., step 1003 of FIG. 10), or cause theaccess gateway to send a ticket (e.g., step 1007 of FIG. 10), etc. Forexample, the technician may view the listing of application or listingof tickets via the user interface, modify the listing via the userinterface, create a ticket to be sent to a mobile device via the userinterface, and cause the access gateway to store and/or send the ticketto the mobile device via the user interface.

The architecture described in this specification can be used by acorporation or other enterprise to flexibly implement a policy, such asa corporate owned device, BYOD (bring your own device) policy, forallowing enterprise users to use their mobile devices to securely accessenterprise resources (documents, confidential data, corporateapplication and database servers, etc.). This is accomplished throughvarious security features that, for example, enable the enterprise tospecify and implement policies for controlling mobile device accesses toparticular enterprise resources. The policies may, for example, controlmobile device accesses to enterprise resources based on a variety ofcriteria, such as the role of the respective user (e.g., whichdepartment the user is in), the configuration of the mobile device(e.g., whether any blacklisted mobile applications are installed), thelogged behaviors of the user, the location of the mobile device, and/orthe time at which access to the enterprise resource is requested. Thearchitecture further enhances security, in some embodiments, by creatingapplication tunnels that enable enterprise mobile applications tosecurely communicate over a network with the enterprise system. Thearchitecture may also enable IT staff to selectively (and remotely) wipea user's mobile device of enterprise application(s) and corporate datawhen, for example, the user discontinues employment or violates acorporate policy (such as if they jailbreak their device or otherwiseuse it in a disallowed configuration).

The use of passcodes (or other types of authentication information) forenterprise applications reduces the likelihood that enterprise resourceswill be improperly accessed when, for example, the mobile device is lostor stolen, or when the mobile device is used by an employee's childrento play games. In some embodiments, the secure launcher (or anothercomponent installed on the mobile device) further reduces this risk byperforming a selective wipe of the mobile device when, for example, theuser attempts but fails to enter a valid passcode a threshold number ofconsecutive times (e.g., 5 or 10). The selective wipe operation deletessome or all of the enterprise applications and associated data from themobile device, without deleting any personal applications or data. Insome embodiments, the enterprise's IT department can initiate aselective wipe of a particular mobile device by remotely issuing a wipecommand to the device.

In some embodiments, when a selective wipe operation is performed, someor all of the documents and data stored in the secure container aredeleted from the mobile device or are otherwise made inaccessible. FIG.11 illustrates a method of providing a selective wipe of data related toproviding per-application policy-controlled VPN tunnels. In one or moreembodiments, the example method of FIG. 11 may be performed by theprocessing circuitry of a mobile device when operating in accordancewith various software constructs stored in the memory of the mobiledevice.

At step 1101, a mobile device may determine to perform a selective wipe.The determination may be received from various sources. For example, theenterprise may send an instruction to perform the selective wipe or themobile device may analyze its status to determine whether to perform aselective wipe. A user may uninstall an application, and the mobiledevice may determine to perform a selective wipe of data associated withmanaging the application. An application may switch from a managed modeto an unmanaged mode, and the mobile device may determine to perform aselective wipe of data that an unmanaged application should not haveaccess to. Other conditions where a selective wipe may be determineinclude determining to perform a selective wipe based on a determinationthat the mobile device is jailbroken or rooted, is installed with ablacklisted application, is not configured with a lock screen, and thelike.

Steps 1103-1109 form part of a process for performing the selectivewipe. Other data may be deleted from the mobile device during theselective wipe process. The below steps are related to identifying anddeleting tickets from secure containers as part of a selective wipeprocess that deletes or otherwise makes inaccessible enterprise dataassociated with the managed application, which may include the policyinformation.

At step 1103, the mobile device may determine that one or more ticketsare stored in one or more secure containers on the mobile device. Insome arrangements, this may include analyzing policy information tocheck for the inclusion of ticket-related information such as, forexample, an identification of a ticket, a location where a ticket isstored, or other identifier of a secure container where a ticket isstored. In some arrangements where the selective wipe is directed atwiping the enterprise data associated with a particular application, thepolicy for the particular application may be analyzed. In someembodiments, the tickets may have been issued in connection withproviding one or more applications access to one or more enterpriseresources (see e.g., FIG. 9).

At step 1105, the mobile device may search one or more secure containersfor the one or more tickets. In some arrangements, the searching for theone or more tickets may be based on the information found in a policythat was analyzed at step 1103. For example, if a policy analyzed atstep 1103 was found to include a particular identification of a ticket,the mobile device may perform the search based on the particularidentification of the ticket. If a policy analyzed at step 1103 wasfound to include a particular location of where a ticket was stored, themobile device may perform the search based on the particular location.

At step 1107, the mobile device may delete or otherwise makeinaccessible the one or more tickets.

At step 1109, the mobile device may transmit a selective wipeacknowledgement to the enterprise. Such an acknowledgement may providean indication to the enterprise that the selective wipe was successful.The acknowledgement may include a listing of applications and/or listingof tickets that were affected/deleted by the selective wipe. Uponreceipt, the enterprise (e.g., access gateway) may update its storedrecords accordingly. For example, an access gateway may receive aselective wipe acknowledgment that includes a listing of applicationand/or listing of tickets that were affected/deleted by the selectivewipe and, respectively, may update its listing of applications installedon the mobile device by removing entries corresponding to theapplication(s) indicated by the acknowledgement and/or update itslisting of tickets issued and valid to the mobile device by removingentries corresponding to the tickets indicated by the acknowledgement.

Managed applications are typically allowed to exchange data with othermanaged applications, but may be constrained or blocked from exchangingdata with other applications, such as the user's own personalapplications. In some examples, application policies of managedapplications are configured to allow links and/or icons presented in onemanaged application to be followed or opened in another application onlyif the other application is also a managed application.

For example, a managed email application can be configured, through itspolicy, to allow an attachment to be opened in a managed PDF annotator.But the same managed email application can be configured to prevent thesame attachment from being opened in a PDF annotator that is not part ofthe managed set.

By constraining managed applications to interact on a mobile devicethrough enterprise-administered policies, the managed set ofapplications can thus be made to operate with other applications in themanaged set of applications, but can be prevented from operating withapplications that are not part of the managed set.

An application may be run on the mobile device in one of a plurality ofoperations modes. The operation modes may comprise, for example, managedand unmanaged modes. There may be multiple different managed modes,e.g., based on different security levels of various users or sets ofcredentials provided by a user, different user roles identified by a setof credentials (e.g., manager versus staff employees), geographiclocations from which the device is operated, network locations,operational environment (e.g., a healthcare-related managed mode versusa financial industry managed mode), or based on any other contextualdetermination.

In an embodiment, the policies may be stored remotely, such as at policymanager 570, described above with reference to FIG. 5, or may be storedlocally on the device. In an example, a selected application configuredto access a secure account, such as an email application configured toaccess a secure email account, may be executed in an operation modebased on the policy. For instance, the stored policy may define that anemail application that is configured to access a secure email account isto be run as a managed application. The stored policy may furtherindicate that the email application, when configured to access apersonal account of the device user, may operate in an unmanaged mode.

In an embodiment, an application running in managed mode may access datastored in a secure data container 528 in the managed partition 510(physical, logical, or virtual) of the mobile device. The data stored inthe secure data container 528 may include data restricted to a specificsecure/managed application 530, shared among other secure/managedapplications, and the like. Data restricted to a secure application mayinclude secure general data 534 and highly secure data 538. Differentlevels and types of security features may be used to differentiatelevels of secure data. In an embodiment, an application running inmanaged mode may save, modify, or delete data in secure data container528. The data saved or modified may be encrypted similar to other datastored in secure data container 528.

In an embodiment, an application running in managed mode may connect toenterprise resources 504 and enterprise services 508 through virtualprivate network connections, as described about with reference to FIG.5. The virtual private network connections may be microVPNs, which arespecific to a particular application, such as the selected application,particular devices, particular secured areas on the mobile device, andthe like. For example, wrapped applications in a secured area of thephone may access enterprise resources through an application specificVPN such that access to the VPN would be granted based on attributesassociated with the application, possibly in conjunction with user ordevice attribute information, and policy information.

In an embodiment, an application running in managed mode may encryptdata transmitted from the application. For example, an applicationrunning in managed mode may be communicating with a computing deviceover a network, and the data transmitted from the application to thedevice may be encrypted. In addition, the data communicated from thecomputing device to the application may also be encrypted, and theapplication running in managed mode may be configured to decrypt thereceived data.

In an embodiment, an application running in managed mode may accessenterprise resources via a secure connection. For example, anapplication may connect over a network, for example, using a microVPN,and may access a secure portal that might not be accessible by unsecuredapplications, such as applications running in unmanaged mode.

In an embodiment, an unmanaged operation mode may include running theapplication as a part of the unmanaged partition 512 (physical, logical,or virtual) of mobile device 502, as described above with reference toFIG. 5. In an unmanaged mode, the application may access data stored inan unsecured data container 542 on the unmanaged partition 512 of themobile device 502. The data stored in an unsecured data container may bepersonal data 544.

In an embodiment, where more than one managed mode is possible, anapplication running in a less secure managed mode may be run similar toan application running in the more secure managed mode, but might notinclude all aspects of the latter. For example, an application runningin the less secure managed mode may have the information transmittedfrom the application over a network encrypted, but the application mightnot have access to secure data container 528, as described withreference to FIG. 5. In another example, an application running in theless secure managed mode may have access to secure data container 528,but might not be able to connect to enterprise resources 504 andenterprise services 508 through virtual private network connections.Accordingly, depending on the determined context, an application runningin a less secure managed mode may include aspects of an applicationrunning in the more secure managed mode and aspects of an applicationrunning in unmanaged mode. In an embodiment, an application running in aless secure managed mode may be run similar to an application running inmanaged mode, but might not include all aspects of the latter. Forexample, an application running in a less secure managed mode may havethe information transmitted from the application over a networkencrypted, but the application might not have access to secure datacontainers, as described with reference to FIG. 5. In another example,an application running in a less secure managed mode may have access tosecure data containers, but might not be able to connect to enterpriseresources and enterprise services through virtual private networkconnections. Accordingly, depending on the determined context, anapplication running in a less secure managed mode may include aspects ofan application running in managed mode and aspects of an applicationrunning in unmanaged mode.

The operation mode of the application may be set based on variouscriteria. For example, as discussed above in connection with FIG. 5, adual mode option (e.g., item 540 of FIG. 5) may present the user with anoption to operate the managed application in an unsecured or unmanagedmode. In addition to the dual option mode being settable by a user, theoption may be directed by the policy of the application. For example,the policy may include a policy decision indicating which mode theapplication is to be operated in. The policy could place additionalconditions on the operation mode, such as by selecting a managed orunmanaged mode based on a current location of the mobile device or basedon what type of network the user is attempting to gain access from(e.g., WiFi, a user's home network, etc.). Such conditions could bereferred to as contexts. These and other aspects will be furtherexplained in connection with FIGS. 12A-12G. In one or more embodiments,the example methods of FIGS. 12A-12G may be performed by the processingcircuitry of a mobile device when operating in accordance with varioussoftware constructs stored in the memory of the mobile device. Howevervarious aspects, in some variations, may be performed by an enterprisedevice, such as device manager 524 of FIG. 5.

In FIGS. 12A-12F, flowcharts of example method steps for determining acontext and operation mode for an application are shown.

In FIG. 12A, a flowchart of example method steps for determining anapplication mode for an application is shown. The method of FIG. 12A maybegin at step 1201, where a plurality of applications are presented. Aplurality of applications may be presented to a user on a mobile device.The method of FIG. 12A may proceed from step 1201 to step 1203, where aselection for one of the plurality of applications is received. A userof a mobile device may select one of the presented applications by, forexample, pressing a display of the mobile device to select theapplication. This is merely an example, and the application may beselected in any suitable manner.

The method of FIG. 12A may proceed from step 1203 to step 1205, where acontext for the selected application is determined based on one or moreoperational parameters of the device executing the selected application.For example, a context may be based on an account to be accessed by theapplication, a location of the mobile device or a network connectivitystatus of the mobile device executing the application, or based on anyother operational parameter. The methods of FIGS. 12B-12E, furtherdescribed below, illustrate various embodiments where example contextsare described.

The method of FIG. 12A may proceed from step 1205 to step 1207, where anoperation mode for the selected application is determined based on thecontext. The operation mode may be determined based on one or moredetermined contexts.

In an embodiment, the determined context may be compared to a storedpolicy in order to determine an operation mode. A mobile device maystore one or more policies used to determine an operation mode for anapplication. In an example, a context may comprise a selectedapplication configured to access a secure account, such as an emailapplication configured to access a secure email account. This contextmay be compared to one or more of the stored policies. For instance, apolicy may define that an email application that is configured to accessa secure email account is to be run as a managed application. Additionalcontexts and policies will be described with respect to FIGS. 12B-12E.

The method of FIG. 12A may proceed from step 1207 to step 1209, wherethe selected application is run in the determined operation mode. Forexample, the operation mode may be determined as managed, unmanaged, orone of the multiple modes that are available, and the selectedapplication may be run in the determined mode.

In an embodiment, an application that is capable of running in managedmode, unmanaged mode, or a less secure managed mode may be controlled bypartition, by policy, by one or more sandboxes, or any other suitableconfiguration. In an embodiment, a managed operation mode may includerunning the application as a part of the managed partition 510 of mobiledevice 502 as discussed above in connection with FIG. 5. In anembodiment, an application running in managed mode may access datastored in a secure data container 528 in the managed partition 510 ofthe mobile device. The data stored in the secure data container 528 mayinclude data restricted to a specific secure application 530, sharedamong other secure applications, and the like. Data restricted to asecure application may include secure general data 534 and highlysecured data 538. Secure general data may use a strong form ofencryption such as AES 128-bit encryption or the like, while highlysecure data 538 may use a very strong form of encryption such as AES254-bit encryption. Other types of encryption may be used, and otherlevels and types of security measures may be applied based on a desiredlevel and/or type of security, as well as different key recoveryfeatures. In an embodiment, an application running in managed mode maysave, modify or delete data in secure data container 528. The data savedor modified may be encrypted similar to other data stored in secure datacontainer 528. In this example, an unmanaged operation mode may includerunning the application as part of unmanaged partition 512, as describedabove.

In an embodiment, an application running in a more secure managed mode,unmanaged mode, or a less secure managed mode may be controlled by oneor more policies. As such, one or more policies may define that theapplication running in managed mode may access secured data (e.g., datain secure data container 528, encrypted data, such as data encryptedwith a particular key, or any other suitable secured data), maycommunicate with a secure server (e.g., gateway server 560), may bemanaged by a device manager (e.g., device manager 524), or any othersuitable policy. One or more policies may also define that theapplication running in an unmanaged mode may not access secure data(e.g., data in secure data container 528, encrypted data, such as dataencrypted with a particular key, or any other suitable secured data),may not communicate with a secure server (e.g., gateway server 560), mayaccess unsecured data (e.g., unsecured data container 542, unencrypteddata, or any other unsecured data), or any other suitable policy. Inthis example, an application running in managed mode and an applicationrunning may either include partitions (e.g., managed partition 510 andunmanaged partition 512) or may not include partitions.

In an embodiment, an application running in a more secure managed mode,unmanaged mode, or a less secure managed mode may be controlled by oneor more sandboxes. A sandbox may comprise a physical or virtualizedportion of a device where applications running in the sandbox mayinclude access policies for applications that are not running in thesandbox. For example, an application running in managed mode may run ina sandbox that includes policies for the managed mode, such as thepolicies described herein. In another example, an application running inunmanaged mode may run in a sandbox that includes policies for theunmanaged mode, such as the policies described herein. In this example,an application running in managed mode and an application running inunmanaged mode may either include partitions (e.g., managed partition510 and unmanaged partition 512) or may not include partitions.

In an embodiment, an application running in managed mode may access datastored in a secure data container 528 in the managed partition 510 ofthe mobile device. The data stored in the secure data container 528 mayinclude data restricted to a specific secure application 530, sharedamong other secure applications, and the like. Data restricted to asecure application may include secure general data 534 and highly securedata 538. Secure general data may use a strong form of encryption suchas AES 928-bit encryption or the like, while highly secure data 538 mayuse a very strong form of encryption such as AES 254-bit encryption. Inan embodiment, an application running in managed mode may save, modify,or delete data in secure data container 528. The data saved or modifiedmay be encrypted similar to other data stored in secure data container528.

In an embodiment, an application running in managed mode may connect toenterprise resources 504 and enterprise services 508 through virtualprivate network connections, as described about with reference to FIG.3. The virtual private network connections may be specific to aparticular application (e.g., a per-application policy-controlled VPNtunnel, such as MicroVPN), such as the selected application, particulardevices, particular secured areas on the mobile device, and the like.For example, wrapped applications in a secured area of the phone mayaccess enterprise resources through an application specific VPN suchthat access to the VPN would be granted based on attributes associatedwith the application, possibly in conjunction with user or deviceattribute information.

In an embodiment, an application running in managed mode may encryptdata transmitted from the application. For example, an applicationrunning in managed mode may be communicating with a computing deviceover a network, and the data transmitted from the application to thedevice may be encrypted. In addition, the data communicated from thecomputing device to the application may also be encrypted, and theapplication running in managed mode may be configured to decrypt thereceived data.

In some variations, the managed application may be run as secure nativeapplications 514, secure remote applications 522 executed by a secureapplication launcher 518, virtualization applications 526 executed by asecure application launcher 518, and the like. The applications may be astabilized application such that the device monitor 524 monitors thestabilized applications to detect and remedy problems that might resultin a destabilized application, such as pushing updates to the stabilizedapplications. The data saved or modified may be encrypted similar toother data stored in secure data container 528. In some arrangements, anunmanaged operation mode may include running the application as part ofunmanaged partition 512, as described above.

In an embodiment, step 1205 to 1209 of FIG. 12A may comprise the methodsteps of any one or more of FIGS. 12B-12F. The method of FIG. 12B maybegin at step 1211, where an account to be accessed by a selectedapplication is detected. For example, a selected application maycomprise an email application and an email account that the emailapplication is configured to access may be detected. In this example,the email application may be able to access multiple email accounts,such as an enterprise email account and a personal email account, andthe account that the email application is configured to access at thetime of running may be determined as the context account to be accessed.

The method of FIG. 12B may proceed from step 1211 to step 1213, where anaccount type of the account to be accessed may be determined. Theaccount type may comprise a context for the selected application. Forexample, a selected application may comprise an email application andthe email application may be configured to access an enterprise account.In another example, the email application may be configured to access apersonal account.

The method of FIG. 12B may proceed from step 1213 to step 1215, where anaccount type may be compared with a policy. For example, a policy maydefine that an email application that is to access an enterprise accountshould run in managed mode and an email application that is to access apersonal account should run in unmanaged mode. The method of FIG. 12Bmay proceed from step 1215 to step 1217, where an operation mode isdetermined based on the comparison.

The method of FIG. 12C may begin at step 1221, where a location for amobile device is determined. For example, a mobile device, such asmobile device 502, may implement the method of FIG. 12C, and a locationfor the mobile device may be determined. The location may be determinedby GPS, signal triangulation, or any other suitable or otherwise knownmanner. The location may comprise a context for the selectedapplication.

The method of FIG. 12C may proceed from step 1221 to step 1223, where adetermined location may be compared with a policy. For example, a policymay define that a selected application run in a more secure managed modewhen in a certain location, for example, on company premises. In anembodiment, a policy may define that a selected application run in aless secure managed mode when in a certain location, for example, whenthe determined location is inside the United States but off companypremises. For example, the less secure managed mode may encryptcommunication to and from the selected application, but might not allowaccess to enterprise resources, such as resources 504. In anotherembodiment, a policy may define that a selected application run inunmanaged mode when in a certain location, for example, when thedetermined location is outside the United States. The method of FIG. 12Cmay proceed from step 1223 to step 1225, where an operation mode isdetermined based on the comparison.

Alternatively or in addition to physical location, a network locationmay also or instead be used to determine whether access is permitted.For example, network location may refer to whether a user is eitherinternal to a data center (or pre-approved Wifi access point), or isexternal to it. Appropriate access modes may be based on such adetermination.

The method of FIG. 12D may begin at step 1231, where it is monitoredwhether a predetermined application is running on a device. For example,a mobile device, such as mobile device 502, may implement the method ofFIG. 12D, and the mobile device may be monitored to determine whether apredetermined application is running. The predetermined application maycomprise any application capable of running on the mobile device. Themonitored predetermined application may comprise a context for theselected application.

The method of FIG. 12D may proceed from step 1231 to step 1233, where amonitored application is compared against a policy. For example, apolicy may define that a selected application run in managed mode when apredetermined application is running and that the selected applicationrun in unmanaged mode when the predetermined application is not running.Additionally, a policy may define that a selected application run inmanaged mode whenever a ticket used to authenticate a user whenestablishing a per-application policy-controlled VPN tunnel (asdescribed above in connection with FIG. 9) is received by the mobiledevice, or when such a ticket is valid and is stored in a securecontainer of the mobile device. A policy may also define that a selectedapplication run in unmanaged mode whenever a ticket is found to be notvalid or to have expired. The method of FIG. 12D may proceed from step1233 to step 1235, where an operation mode is determined based on thecomparison.

The method of FIG. 12E may begin at step 1241, one or more networkconnections are detected. For example, a mobile device, such as mobiledevice 502, may implement the method of FIG. 12E, and the networkconnections that the mobile device makes may be detected. In an example,network connections may comprise a connection to a cellular network, aconnection to a WIFI network, or a connection to a Wireless Local AreaNetwork (WLAN), or the like. The one or more network connections maycomprise a context for the selected application.

The method of FIG. 12E may proceed from step 1241 to step 1243, wheredetected network connections are compared against a policy. For example,a policy may define that a selected application run in managed mode whena mobile device is connected to an internal network, such as a WLANinternal to a company, and that the selected application run inunmanaged mode when the mobile device is only connected to a wirelessnetwork, such as cellular network or WIFI network. The method of FIG.12E may proceed from step 1243 to step 1245, where an operation mode isdetermined based on the comparison.

The method of FIG. 12F may begin at step 1251, where one or moresettings for a mobile device are detected. For example, a mobile device,such as mobile device 502, may implement the method of FIG. 12F, and oneor more settings for the mobile device may be detected. In an example,it may be detected whether the mobile device has a lock screen, such asa PIN required for using the mobile device, or it may be detectedwhether the mobile device is jailbroken or rooted, e.g., has receivedafter-market modifications. The one or more settings may comprise acontext for the selected application.

The method of FIG. 12F may proceed from step 1251 to step 1253, wheredetected settings are compared against a policy. For example, a policymay define that a selected application might not run in managed mode ifthe mobile device does not have a lock screen or if the mobile device isjailbroken or rooted. The method of FIG. 12F may proceed from step 1253to step 1255, where an operation mode is determined based on thecomparison. In an embodiment, when running the selected application inthe determined mode, an indicator may be displayed on the mobile devicethat informs a user of certain policies, such as a requirement for amobile device to have a lock screen before the mobile device is allowedto run the selected application in managed mode. FIGS. 12B-12F describea plurality of contexts, and any other suitable context andcorresponding policy may be implemented.

In an embodiment, one or more of the contexts described in FIGS. 12B-12Fmay be combined and these contexts may be compared against a policy forthe selected application. For example, contexts for a selectedapplication may comprise an account type to be accessed as an enterpriseemail account and a detected network connection as a cellular network.In this example, the policy may define that when an enterprise accountis attempted to be accessed over a cellular network, the selectedapplication should be run in managed mode. The policy may be defined inthis way because the selected application may encrypt the communicationwith the enterprise email account, and therefore the risk of sendingsecure traffic over a cellular network may be mitigated.

In another example, contexts for a selected application may comprise adetermined location outside of the United States and a networkconnection with a WLAN internal to a company. A policy may define that aselected application is to run in managed mode when a determinedlocation is outside the United States and a network connection is with aWLAN internal to a company. The policy may be defined in this waybecause a network connection with a WLAN internal to a company mitigatesthe risk associated with secure communications outside of the UnitedStates.

In an embodiment, the one or more contexts as described in FIGS. 12B-12Fmay include a priority. For example, a context for a selectedapplication may comprise a mobile device setting as jailbroken (orrooted) and a policy may define that a selected application is to run inunmanaged mode when a context indicates a jailbroken mobile device (orrooted mobile device), regardless of what other contexts indicate.Accordingly, a jailbroken mobile device (or rooted mobile device) willhave a selected application run in unmanaged mode even when the mobiledevice is connected to a WLAN internal to a company or if the selectedapplication is attempting to access an enterprise account.

In an embodiment, a policy may indicate that a selected application isto be run in a less secure managed mode based on a plurality of contextsas described in FIGS. 12B-12F. For example, contexts for a selectedapplication may comprise an account type to be accessed as an enterpriseemail account and a detected network connection as a cellular network.In this example, the policy may define that when an enterprise accountis attempted to be accessed over a cellular network, the selectedapplication should be run in a less secure managed mode. The less securemanaged mode may encrypt communication to and from the selectedapplication, but might not allow access to enterprise resources, such asresources 504. The policy may be defined in this way because theencrypted communication with the enterprise email account may be a lowrisk communication, and allowing access to enterprise resources may be ahigh risk communication.

In FIG. 12G, a flowchart of example method steps for switching anoperation mode for an application is shown. For example, the methodsteps of FIG. 12G may follow the method steps of FIG. 12A. The method ofFIG. 12G may begin at step 1261, where one or more contexts may bemonitored while a selected application is running In an embodiment, oneor more of the contexts described with reference to FIGS. 12B-12F may bemonitored. For example, a mobile device running a selected applicationmay be connected to a cellular network and while the selectedapplication is running, the mobile device may make a new networkconnection with a WLAN internal to a company.

The method of FIG. 12G may proceed from step 1261 to step 1263, where achange in an operation mode for a selected application is detected basedon the monitoring. Stated differently, the mobile device may detect achange in information that formed the basis for selecting a particularoperational mode. For example, a selected application may be running inunmanaged mode, and once a mobile application running the selectedapplication connects to a WLAN internal to a company, a policy maydefine that the operation mode for the selected application shouldswitch to managed mode. Any of the above contexts described inconnection with FIGS. 12B-12E may be used in detecting whether a changein information has occurred. The method of FIG. 12G may proceed fromstep 1263 to step 1265, where the operation mode for the selectedapplication is switched. In some variations, switching an operation modemay include moving the application from the managed partition to anunmanaged partition, or vice versa. Switching an operation mode may alsoinclude performing a selective wipe (as described in connection withFIG. 11), such as when an application switches from a managed mode to anunmanaged mode.

As discussed above, a user may proceed through an authentication process(e.g., user authentication) to access enterprise resources. In someembodiments, this may be performed via a SSO process (e.g., SSO MutualSSL, limited or full Kerberos using passwords or client certificates).In various embodiments, the per-application policy controlled microVPNtunnel, the tickets received/stored by a mobile to authenticate a userwhen establishing such a tunnel (see, e.g., FIG. 9), the access gateway,and other aspects may form a basis for providing authentication-relatedprocesses that can improve the user's experience, such as by providing amore seamless user experience. FIGS. 13A-13C illustrate example methodsfor providing authentication-related functionality in accordance withvarious aspects described herein.

FIG. 13A illustrates a method for responding to authenticationchallenges at a mobile device. In one or more embodiments, the examplemethod of FIG. 13A may be performed by the processing circuitry of amobile device when operating in accordance with various softwareconstructs stored in the memory of the mobile device.

At step 1301, a mobile device may receive an authentication challenge inconnection with an authentication process for a managed application. Forexample, a mobile device, when performing an authentication process mayreceive and/or exchange HTTP status codes with an enterprise that causesreceipt of an authentication challenge, such as HTTP 401 codes forrequesting authentication, and/or challenge-response messages. Based onthe type of authentication, an enterprise resource may send anauthentication challenge. For Kerberos authentication, a PKINIT protocolmay be used. The enterprise resource may generate a Kerberosauthentication challenge, such as HTTP 401 Negotiate. For SSLauthentication (e.g., using a client certificate), an enterpriseresource may generate a client certificate challenge. In somevariations, the mobile device identifies receipt of an authenticationchallenge by monitoring network traffic, including network trafficflowing within a per-application policy-controlled VPN tunnel, such as aMicroVPN. Additionally, receiving the authentication challenge mayinclude intercepting the authentication challenge before it is receivedby an application.

Upon receiving the authentication challenge, the mobile device mayproceed from step 1301 to step 1303, where the mobile device maydetermine whether a policy allows for the mobile device to respond tothe authentication challenge instead of a user or managed application.For example, a policy may define that a mobile device can send responsesto authentication challenges based on a listing of allowed sources(e.g., the mobile device may respond if the authentication challenge isreceived from a sharepoint or an exchange server, or the like). A policymay define that a mobile device can send responses to authenticationchallenges based on the mobile device having a token that is valid forthe application. In some variations, the mobile device may determinewhether the mobile device has a token that is valid and/or not expiredfor the application similar to step 905 of FIG. 9.

If it is determined that the mobile device is allowed to respond to theauthentication challenge, the method may proceed to step 1305. Otherwise(e.g., the ticket for the managed application is expired), the methodmay proceed to step 1307 where the authentication challenge is providedfor further processing in accordance with conventional methods ofresponding to authentication challenges (e.g., provided to theapplication, provided to the user a notification that directs the userto select credentials to send as a response to the authenticationchallenge, etc.).

At step 1305, the mobile device may respond to the authenticationchallenge. Responding to the authentication challenge may includeanalyzing the challenge to identify what is being requested; locatingany credential, certificate, etc., requested by the challenge;generating the response and transmitting the response to the source ofthe authentication challenge. In some variations, responding theauthentication challenge may include transmitting the response using aper-application policy-controlled VPN tunnel, such as the tunnel beingused by the managed application that the authentication challenge wasoriginally directed to.

In some variations, steps 1301-1305 may proceed without the applicationand/or the user being aware of the authentication challenge. Forexample, the mobile device may intercept the authentication responseprior to being received by the application, or the user may not bepresented with a message regarding the authentication challenge.

In addition to being performed by the mobile device, the access gatewaymay perform a similar method. For example, the access gateway mayintercept an authentication challenge similar to step 1301. The accessgateway may determine whether a policy allows for the access gateway torespond to the challenge on behalf of the mobile device similar to step1303. The access gateway may also respond to the challenge similar tostep 1305.

Furthermore, a method similar to that illustrated in FIG. 13A may beperformed using a combination of the mobile device and access gateway.For example, the access gateway may intercept an authenticationchallenge similar to step 1301. The access gateway may communicate withthe mobile device to determine whether the access gateway or the mobiledevice should respond to the challenge. The mobile device may perform adetermination similar to step 1303 to determine whether the accessgateway or the mobile device is authorized by a policy to respond to thechallenge. If the access gateway or the mobile device is allowed torespond, the appropriate device may proceed with the response similar tostep 1305.

FIG. 13B illustrates a method for providing tokens, certificates, orother credentials from an access gateway to one or more mobile devices.The example method of FIG. 13B may be performed by the processingcircuitry of an access gateway (authentication server) when operating inaccordance with various software constructs stored in the memory of theaccess gateway.

At step 1321, the access gateway (or authentication server) may receivea message in connection with an initial authentication of an applicationor a mobile device. For example, the message may be in connection withan initial authentication process that authenticates a user prior toallowing a managed application, which is executing on a mobile device,access to enterprise resources In some arrangements, the enterprise maysend the message (e.g., a command to send authentication credentials andthe like to registered mobile devices of a user). In others, the mobiledevice may transmit the message as part of its initial authenticationprocess (e.g., similar to step 901 of FIG. 9).

At step 1323, the access gateway may determine credential informationassociated with the requesting user, application, mobile device, oraccount of the user. For example, the access gateway may maintain alisting of tokens that have been issued (or can be issued) to a mobiledevice or have been issued to any mobile device associated with the user(e.g., registered devices). The access gateway may also maintain alisting of policies (e.g., policy information) that are linked to theuser. The access gateway may also maintain a listing of certificatesthat are linked to the user. In some arrangements, an enterpriseoperator may input or modify the listings (e.g., an IT technician maysetup the listings manually). In others, the access gateway may createand modify the listings based on traffic being sent to mobile devicesregistered to the user (e.g., add a ticket or certificate to a listingwhen such is sent to a mobile device registered to the user).

At step 1325, the access gateway may transmit the credential informationto one or more mobile devices. For example, the access gateway maytransmit the credential information to a single mobile device (e.g., inresponse to a request for particular types of credential information; orin response to receiving a direction to send credential information to aparticular mobile device, etc.). The access gateway may also transmitthe credential information to a plurality of mobile devices (e.g., inresponse to a request from a particular mobile, the access gateway maytransmit the credential information to all devices registered with theenterprise for the user; or in response to receiving a direction to sendto multiple devices, the access gateway may transmit the credentialinformation to the multiple devices, etc.).

In some variations, the credential information may include informationthat is both responsive to the message received at step 1321 andadditional information that is not specifically responsive to themessage. For example, a mobile device may transmit a message requestinginitial authorization of the mobile device and may provide credentialsto perform the initial authorization. Responsive to the message, theaccess gateway may perform the initial authorization and, assuming thesupplied credentials are validated, the access gateway may transmitcredential information that identifies the initial authorization assuccessful (e.g., information responsive to the message) and maytransmit tickets, certificates, policies, and/or the like to the mobiledevice (e.g., additional information that is not specifically responsiveto the message).

In some variations, transmitting the credential information may includetransmitting using a per-application policy-controlled VPN tunnel, suchas the MicroVPN tunnels illustrated in FIG. 5 and further describedthroughout the disclosure, such as in connection with FIG. 9.

FIG. 13C illustrates an example method for providing certificates from amobile device. In one or more embodiments, the example method of FIG.13C may be performed by the processing circuitry of a mobile device whenoperating in accordance with various software constructs stored in thememory of the mobile device. While the example depicted in FIG. 13C willbe discussed in connection with transmitting certificates used by amanaged browser, similar techniques could be used to providecertificates from a mobile device for different types of application.

For example, an enterprise resource or a website being accessed via amanaged application, such as a managed browser, may demand a certificatefrom the user or mobile device. Accordingly, at step 1341, the mobiledevice may receive a message representing a demand or challenge for thecertificate. In addition to a managed browser, other application typesmay demand a certificate. For example, a managed application may berunning in a managed browser. The managed application may also be anapplication that communicates using an HTTP or HTTPS protocol (similarto how a managed browser uses HTTP or HTTPS protocols), or otherweb-based protocol. The remaining portion of FIG. 13C will be discussedin terms of a managed browser, but certificate demands in connectionwith a managed application running within a browser or a managedapplication that uses HTTP, HTTPS or other web-based protocol could beresponded to in a similar fashion.

Conventionally, a user may be asked by the browser to provide acertificate. However, at step 1343, the mobile device may analyze apolicy associated with the managed browser to determine whether thepolicy allows for the mobile device to provide the certificate insteadof a user or the managed browser (e.g., without receiving input orotherwise notifying the user of the message or demand for certificate).For example, a policy may define that a mobile device can sendcertificates based on a listing of certificates or types of certificatesthat may be sent (e.g., the mobile device may respond if the requestedcertificate is found on the list). A policy may define that a mobiledevice can send certificates based on the mobile device having a tokenthat is valid for the browser application. In some variations, themobile device may determine whether the mobile device has a token thatis valid for the browser similar to step 905 of FIG. 9.

In one or more embodiments, the mobile device may recognize the messageas a certificate request (e.g., a PK operation ‘authentication’protocol). Accordingly, the mobile device may decode the message fromthe received header format and pass a binary structure of the messagefor additional processing, such as via a PKOperation SDK. ThePKOperation SDK may have knowledge of the available clientcertificate(s). The certificates may be in the form of a physical smartcard, a virtual smart card, and the like. The PKOperation SDK may decodethe message (including processing any encryption/integrity wrappers),and dispatch it to an appropriate internal handler. The handler mayprocess the message and generate a list of available certificates. Thelist of certificates may be filtered according to relevance for theoperation being requested, for example, to only include certificateswith an appropriate key usage indicator. The list of certificates may befiltered until only one certificate remains. Such filtering may beperformed based on the policy for the browser application. The list maybe in a binary structure that represents the operation result. ThePKOperation SDK may return the list of certificates, which may still bein the binary structure or signal an error condition if the list cannotbe generated.

If it is determined that the mobile device is allowed to send acertificate, the method may proceed to step 1345. Otherwise, method mayproceed to step 1347 where the message is provided for furtherprocessing in accordance with conventional methods of sendingcertificates (e.g., asking the user to select a certificate to send as aresponse to the message).

At step 1345, the mobile device may transmit the certificate responsiveto the request. Transmitting the certificate may include locating anycertificate that is to be sent. In some variations, responding theauthentication challenge may include transmitting the certificate usinga per-application policy-controlled VPN tunnel, such as the tunnel beingused by the browser application.

In some variations, steps 1341-1345 may proceed without the applicationand/or the user being aware of the certificate demand (e.g., the usermay not be presented with a message regarding the authenticationchallenge).

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined any claim is not necessarily limited tothe specific features or acts described above. Rather, the specificfeatures and acts described above are described as some exampleimplementations of the following claims.

We claim:
 1. A method, comprising: storing, by a mobile device, a ticketin a secure container usable to store data related to a managedapplication being provided by the mobile device, wherein the ticket isconfigured to provide authentication in connection with creating avirtual private network (VPN) tunnel for the managed application to atleast one resource accessible through an access gateway; providing themanaged application with access to the at least one resource based onthe ticket, the VPN tunnel, and policy information that describes one ormore policies for providing the managed application of the apparatuswith access to the at least one resource; determining to perform aselective wipe; determining that the ticket is stored by the mobiledevice; and deleting the ticket from the secure container.
 2. The methodof claim 1, further comprising: storing, at the mobile device, thepolicy information in the secure container; and deleting the policyinformation as part of a selective wipe process that deletes secureddata associated with the managed application.
 3. The method of claim 2,further comprising: searching the secure container for the ticket basedon information included in the policy information.
 4. The method ofclaim 1, further comprising: transmitting a selective wipeacknowledgement to the access gateway, wherein the acknowledgementincludes a listing of tickets that were deleted during the selectivewipe.
 5. The method of claim 1, wherein determining that the ticket isstored by the mobile device includes analyzing the policy informationfor an identification of the ticket or a location where the ticket isstored.
 6. The method of claim 1, wherein the VPN tunnel is aper-application policy-controlled VPN tunnel that provides only theapplication with access to the at least one resource.
 7. The method ofclaim 1, wherein determining to perform the selective wipe is based onthe managed application being switched from a managed mode of operationto an unmanaged mode of operation.
 8. The method of claim 1, whereindetermining to perform the selective wipe is based on one or more of thefollowing: a determination that the mobile device is jailbroken orrooted, a determination that the mobile device is installed with ablacklisted application, or a determination that the mobile device isnot configured with a lock screen.
 9. The method of claim 1, whereindetermining to perform the selective wipe is based on the managedapplication being uninstalled.
 10. An apparatus, comprising: at leastone processor; and memory storing executable instructions configured to,when executed by the at least one processor, cause the apparatus to:store a ticket in a secure container usable to store data related to amanaged application being provided by the apparatus, wherein the ticketis configured to provide authentication in connection with creating avirtual private network (VPN) tunnel for the managed application to atleast one resource accessible through an access gateway, provide themanaged application with access to the at least one resource based onthe ticket, the VPN tunnel, and policy information that describes one ormore policies for providing the managed application of the apparatuswith access to the at least one resource, determine to perform aselective wipe, determine that the ticket is stored by the mobiledevice, and delete the ticket from the secure container.
 11. Theapparatus of claim 10, wherein the executable instructions areconfigured to, when executed by the at least one processor, furthercause the apparatus to: store the policy information in the securecontainer; and delete the policy information as part of a selective wipeprocess that deletes secured data associated with the managedapplication.
 12. The apparatus of claim 10, wherein the executableinstructions are configured to, when executed by the at least oneprocessor, further cause the apparatus to search the secure containerfor the ticket based on information included in the policy information.13. The apparatus of claim 10, wherein the executable instructions areconfigured to, when executed by the at least one processor, furthercause the apparatus to transmit a selective wipe acknowledgement to theaccess gateway, wherein the acknowledgement includes a listing oftickets that were deleted during the selective wipe.
 14. The apparatusof claim 10, wherein determining that the ticket is stored by the mobiledevice includes analyzing the policy information for an identificationof the ticket or a location where the ticket is stored.
 15. Theapparatus of claim 10, wherein the VPN tunnel is a per-applicationpolicy-controlled VPN tunnel that provides only the application withaccess to the at least one enterprise resource.
 16. The method of claim1, wherein determining to perform the selective wipe is based on one ormore of the following: the managed application being switched from amanaged mode of operation to an unmanaged mode of operation, the managedapplication being uninstalled, a determination that the mobile device isjailbroken or rooted, a determination that the mobile device isinstalled with a blacklisted application, or a determination that themobile device is not configured with a lock screen.
 17. One or morenon-transitory computer-readable media storing instructions configuredto, when executed, cause at least one computing device to: store aticket in a secure container usable to store data related to a managedapplication being provided by the apparatus, wherein the ticket isconfigured to provide authentication in connection with creating avirtual private network (VPN) tunnel for the managed application to atleast one resource accessible through an access gateway; provide themanaged application with access to the at least one resource based onthe ticket, the VPN tunnel, and policy information that describes one ormore policies for providing the managed application of the apparatuswith access to the at least one resource; determine to perform aselective wipe; determine that the ticket is stored by the mobiledevice; and delete the ticket from the secure container.
 18. The one ormore non-transitory computer-readable media of claim 17, wherein theinstructions are configured to, when executed, further cause said atleast one computing device to: store the policy information in thesecure container; delete the policy information as part of a selectivewipe process that deletes secured data associated with the managedapplication; and search the secure container for the ticket based oninformation included in the policy information.
 19. The one or morenon-transitory computer-readable media of claim 17, wherein theinstructions are configured to, when executed, further cause said atleast one computing device to transmit a selective wipe acknowledgementto the access gateway, wherein the acknowledgement includes a listing oftickets that were deleted during the selective wipe.
 20. The one or morenon-transitory computer-readable media of claim 17, wherein determiningthat the ticket is stored by the mobile device includes analyzing thepolicy information for an identification of the ticket or a locationwhere the ticket is stored.